测试基于SQL Server 2008 AdventureWorks2008,TablePerson.Person.表中已经存在的索引定义:
CREATE NONCLUSTEREDINDEX [IX_Person_LastName_FirstName_MiddleName]ON [Person].[Person]
(
[LastName] ASC,
[FirstName] ASC,
[MiddleName] ASC
)WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,SORT_IN_TEMPDB=OFF,IGNORE_DUP_KEY=OFF,
DROP_EXISTING=OFF,ONLINE=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON [PRIMARY]
GO
我想根据FirstName查询LastName,执行后看执行计划:
可以看到SQL Server执行了Index Scan,虽然SQL Server没有以FirstName开头的索引。刚开始学习SQL Server的时候认为SQL Server只有filter的字段是索引的第一个字段时才可以使用索引。其实看过这个例子就知道,这个理解是不对的。因为之前在表上已经存在了LastName的索引,SQL Server引擎会知道索引中存在FirstName的字段,而且Index的Page页面的数量远远少于整张表Page的数量,所以用Index Scan是最快的方法,所以仍然会使用Index Scan.
回到SQL Server给出的Missing Index脚本:
USE [AdventureWorks2008]
GO
CREATENONCLUSTEREDINDEX [ix1]
ON [Person].[Person]([FirstName])
可以看到SQL Server使用了Index Scan+Key Lookup,而且Key Lookup的Cost占到了87%。解决Key Lookup的问题我们可以使用Include Index,将这个字段包含到上面创建的索引中。索引修改后的代码:
USE[AdventureWorks2008]
GO
CREATENONCLUSTEREDINDEX [ix_firstname]
ON[Person].[Person]([FirstName])
include(LastName)
重新运行看到SQL Server 选择了Index Seek:
这次的性能要比上次的好,使用下面的脚本可以证明:
setstatisticsioon
go
setstatisticstimeon
go
select LastName from Person.Personwhere FirstName ='ken'
setstatisticsiooff
go
setstatisticstimeoff
go
所以即使SQL Server给出的Missing Index 也要最好分析之后进行使用。创建Index之后要关注Index的使用状况,比如Seek/Scan/Lookup/Update的比例,根据这些数据,进行相应的调整。因为对于更新多而查询非常少的案例,创建多的索引可能会在造成负担。