测试基于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,执行后看执行计划：

 

 

203828125.png

 

可以看到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])

 

203831563.png

 

可以看到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：

 

 203833178.png

 

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

 

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的比例，根据这些数据，进行相应的调整。因为对于更新多而查询非常少的案例，创建多的索引可能会在造成负担。