分析SQL Server 给出的missing index建议

测试基于SQL Server 2008 AdventureWorks2008,TablePerson.Person.表中已经存在的索引定义：

 

CREATE NONCLUSTERED INDEX [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,虽然SQLServer没有以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%。解决KeyLookup的问题我们可以使用IncludeIndex,将这个字段包含到上面创建的索引中。索引修改后的代码：

 USE[AdventureWorks2008]

GO

CREATENONCLUSTEREDINDEX [ix_firstname]

ON[Person].[Person]([FirstName])

include(LastName)

 

重新运行看到SQL Server 选择了Index Seek：

 这次的性能要比上次的好，使用下面的脚本可以证明：

 

 set statistics io on

go

set statistics time on

go

select LastName from Person.Personwhere FirstName ='ken'

set statistics io off

go

set statistics time off

go

所以即使SQL Server给出的Missing Index也要最好分析之后进行使用。创建Index之后要关注Index的使用状况，比如Seek/Scan/Lookup/Update的比例，根据这些数据，进行相应的调整。因为对于更新多而查询非常少的案例，创建多的索引可能会在造成负担。