测试基于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,虽然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
CREATE NONCLUSTEREDINDEX [ix1]
ON [Person].[Person]([FirstName])
可以看到SQL Server使用了Index Scan+Key Lookup，而且Key Lookup的Cost占到了87%。解决KeyLookup的问题我们可以使用IncludeIndex,将这个字段包含到上面创建的索引中。索引修改后的代码：
USE[AdventureWorks2008]
GO
CREATE NONCLUSTEREDINDEX [ix_firstname]
ON[Person].[Person]([FirstName])
include(LastName)
重新运行看到SQL Server 选择了Index Seek：
这次的性能要比上次的好，使用下面的脚本可以证明：
set>'ken'
set statisticsio off
go
set statisticstime off
go
所以即使SQL Server给出的Missing Index也要最好分析之后进行使用。创建Index之后要关注Index的使用状况，比如Seek/Scan/Lookup/Update的比例，根据这些数据，进行相应的调整。因为对于更新多而查询非常少的案例，创建多的索引可能会在造成负担。