使用SQL Server索引密度对行数（Estimating Rows Using the Index Statistics）进行评估的实际操作步骤，同时本文也有对通过优化器是如何正确的使用索引密度来决定一个索引的效果的描述，望大家会有所收获。
当在一个范围内查找一个索引值或者键中存在重复值时，SQL Server会使用直方图信息。考虑下面关于bigpubs2000数据库中的sales表中查询：
Sql代码
Select * from sales Where title_id = 'BI2184' Select * from sales Where title_id = 'BI2184'
因为在表中title_id中存在重复值，SQL Server使用关于title_id的直方图（参考Listing34.2）来估计匹配的行数。对于BI2184值，它将查看EQ_ROWS值，值为343.0。这表示在表中title_id值为BI2184的记录共有343行。
当一个查询参数（search argument）的精确匹配（exact match 即等号计算）在直方图中step没有发现时，SQL Server使用比查找值（search value）大的下一个step中的AVG_RANG_ROWS值。例如，SQL Server对查找值为‘BI2187’进行评估，它将会发现匹配值为270.0行。
对一个范围检索，SQL Server把检范围两端的RANG_ROW和EQ_ROWS相加。例如，利用Listing34.2中的直方图，假如查找参数为 where title_id <= 'BI2574',行数估计将是：
314 + 613 + 343 + 270 + 277，或者为1817。
当直方图不能使用时，SQL Server就使用索引密度来估计匹配行数。对于等值查找的计算公式是直截了当的，例如：
Sql代码 Declare @tid varchar(6) Select @tid = 'BI2574' Select count(*) from sales where title_id = @tid Declare @tid varchar(6) Select @tid = 'BI2574' Select count(*) from sales where title_id = @tid
行估计值等于指定键值的SQL Server索引密度（1.8621974E-3）乘以表中行数：
Sql代码 Select count(*) * 1.8621974E-3 From sales Go Select count(*) * 1.8621974E-3 From sales Go 314.19925631500001
假如一个查询的SARG为title_id 和stor_id，并且假如title_id的SARG是一个可在优化期间可评价的常量表达式，SQL Server会用title_id stor_id的索引密度和title_id的直方图来估计匹配的行数（对某些值来说，索引密度估计的值可能会大学直方图估计出来的值）。SQL Server 将会用二者中较小的值作为匹配的行数。
根据title_id stor_id的SQL Server索引密度，你能看到：
Sql代码 Select coun(*) * 5.997505E-6 From sales Select coun(*) * 5.997505E-6 From sales 1.011929031125
在这个例子中，SQL Server将用title_id 和stor_id的SQL Server索引密度来估计匹配的值。在此情况下，它估计查询将返回一条匹配的行。
生成和维护索引统计
现在，你也许会问“入户创建索引统计，并且如何维护他们？”当你在一个表上创建一个索引时候索引统计就会第一次被创建，或者当你运行UPDATE STATISTICS 命令时。在7.0以前的版本中，索引统计信息不会自动更新。
假如当索引创建之后，你插入许多行，那么反映索引统计的直方图信息不会反映实际的键值分布。结果，优化器有时选择了一个低效率的执行计划。作为一个常规的日常委会工作，DBA只好创建一个schedule运行UPDATE STATISTICS来保持索引统计的及时更新。7.0以后的版本，