SQL Server索引的执行计划

如何知道索引有问题，最直接的方法就是查看执行计划。通过执行计划，可以回答表上的索引是否被使用的问题。

（1）包含索引：避免书签查找

常见的索引方面的性能问题就是书签查找，书签查找分为RID查找和键值查找。

当非聚集索引被用于查找数据，但又不能覆盖查询时，就会引起书签查找。此时优化器会借助堆上的RID或者聚集索引上的聚集索引键来查找所需的额外数据，前者叫做RID，后者叫做键值查找。

书签查找就是为了找额外的列，如果数据量少并不是什么问题，但是当数据量很大，额外的列很多时，往往会带来额外的I/O开销，影响性能。

	select sod.ProductID,sod.OrderQty,sod.UnitPrice
	 from Sales.SalesOrderDetail sod where sod.ProductID=897

　　

 这个的性能根源----其实就是在键值查找上。对策，尽量使用查询在一个索引中完成，这一步可以通过覆盖索引和包含索引来实现。

if exists 
(select * from sys.indexes where 
object_id=OBJECT_ID(N'Sales.SalesOrderDetail') 
and name=N'IX_SalesOrderDetail_ProductID')
drop index IX_SalesOrderDetail_ProductID on Sales.SalesOrderDetail with (online=off);

　　创建索引：

create nonclustered index IX_SalesOrderDetail_ProductID 
on Sales.SalesOrderDetail(ProductID asc)
include (OrderQty,UnitPrice) 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];

　　再次执行上述语句，执行计划如下：

逻辑读从1240下降到3次，是一个很大的提升，从实践来说，书签查找是常见的性能问题标志，当出现这个操作符，且百分比相对较高时，就必须分析是否有必要调整优化。

（2）索引选择度

对于每个索引，优化器都会自定创建统计信息来描述这个索引的数据分布情况。在后续的使用中，优化器会根据这些统计信息来决定查询是否使用这些索引。

通过以下语句可以查看统计信息：

dbcc show_Statistics('Sales.SalesOrderDetail','IX_SalesOrderDetail_ProductID')

　　

这个索引上的ProductID的密度为0.0037593999，是非常低的值也就是选择度很高，最优可能被使用，而其他两行是聚集索引的列，由于非聚集索引的叶子节点会指向聚集索引键，这里的统计信息会包含这两列，并同时给出对应的密度。如果表上没有聚集索引，那么非聚集索引会指向数据本身。如果选择度很低，优化器会放弃索引。

select sod.OrderQty,sod.SalesOrderID,
sod.SalesOrderDetailID,sod.LineTotal from Sales.SalesOrderDetail sod where sod.OrderQty=10;

　　

优化器使用了聚集索引扫描来实现WHERE条件的筛选操作。对这个列加上索引。

create nonclustered Index IX_SalesOrderDetail_OrderQty
on Sales.SalesOrderDetail(orderQty 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]

　查看统计信息：

dbcc SHOW_STATISTICS('Sales.SalesOrderDetail','IX_SalesOrderDetail_OrderQty')

　　

这个选择度不高，如果再次执行查询语句，可以看到执行计划中依旧会使用原有计划。

如果选择度不高，优化器依旧会放弃上面的索引。

删除新建的索引：

drop index Sales.SalesOrderDetail.IX_SalesOrderDetail_OrderQty

　　（3）统计信息和索引

优化器会对每个索引创建统计信息，如果统计信息过时，优化器同样可能不选择“有用索引”。

if EXISTS (select * from sys.objects where object_id=OBJECT_ID('N[NewOrders]') and type in (N'U'))
drop table[NewOrders]
go
select * into NewOrders from Sales.SalesOrderDetail
go
create index IX_NewOrders_ProductID on NewOrders(ProductID)

　　使用一个简答的查询生成预估执行计划，接着在事物中更新数据，影响ProductID列上的数据分布，让其选择度变低。最后获取实际执行计划。

set showplan_xml on
go
select OrderQty,CarrierTrackingNumber from NewOrders where ProductID=897
go
set showplan_xml off

预估执行计划：

begin tran
update NewOrders
set ProductID=897
where ProductID between 800 and 900

--实际的执行计划
set statistics xml on
go
select OrderQty,CarrierTrackingNumber from NewOrders where ProductID=897
rollback tran
go
set statistics xml off

　　实际执行计划：

由于统计信息得变更，优化器对同一个查询选择不同的执行计划。更新操作使得列上的数据分布发生改变，选择度降低，优化器会“觉得”使用扫描操作时开销更低。因此，确保统计信息得实时性及有效性对性能的提升非常重要。