此文章主要向大家描述的是SQL Server非聚集索引（Noclustered Index Indications），在实际操作中SQL Server 2000数据库可以允许你在一个表上最大程度的创建249个非聚集索引。直到表变得非常巨大，一个非聚集索引实际所占用的空间与日益增长的访问性能相比是微不足道的。
然而，时刻牢记：随着你在系统添加更多索引，数据修改语句由于索引性能的负担会变得更慢。
当定义SQL Server非聚集索引时，你也想在选择性高的列上定义索引（也就是，具有低密度值的列）这样它们能被优化器来使用。一个非聚集索引中的大量重复值经常使得使用非聚集索引比表扫描代价更高（按照I/O）。让我们一起来看一个假设的例子：
- Sql代码
- Select title from titles
- Where price between $5 and $10
- Select title from titles
- Where price between $5 and $10
假设你在范围内有1，000，000行；这些1，000，000行随机分散在整个表中。尽管索引叶级拥有全部的有序索引行，但在最坏情况下，一次读一个数据行也将要求一个书签查找。
这样，在最坏情况下使用SQL Server非聚集索引来进行范围检索的I/O估计如下：
引用
非聚集索引的层数
+用于发现所有匹配行的扫描的索引页数
+ 匹配的行数 × 每个书签查找的页数
假如你的表上没有聚集索引，那书签仅仅是一个包括页和行的指针，当发现匹配的数据行时需要读取一个数据页。假如范围内有1，000，000行，当该表没有聚集索引时，借助非聚集索引的最坏情况的估计是：
引用
查找所有书签需要读取的索引页数
+1，000，000匹配行 × 1数据页的读取
= 1，000，000 +I/Os
如果表中有聚集索引，书签就是一个代表数据行的聚集索引键，用书签来查找匹配的行要求搜索聚集索引树来定位数据行。假设聚集索引有两级非叶子节点，它将需要读取三页来在数据页上查找每个满足条件的行。如果范围内有1，000，000行，那么借助聚集索引的SQL Server非聚集索引来查找数据，在最坏情况下它的代价估计如下：
引用
查找所有书签所读取的索引页的个数
+1，000，000匹配的行 * 每个书签查找需求的3页
=3，000，00+I/Os
把每种情况与表扫描相对比。如果整个表占用了50，000页，那么一个全表扫描将只花费50，000 I/O。所以，在这个例子中，一个表扫描实际将比用非聚集索引更有效。
下面的指南帮助你识别非聚集索引的潜在的候选者。
SARG或join子句中引用的相对来说具有较高的选择性（密度值低）的列。
Where子句和order by子句都引用的列。
当使用非聚集索引来检索数据行时，它们按照非聚集索引键的顺序被检索出来。如果结果集也需要按照SQL Server非聚集索引进行排序，SQL Server能避免对结果集重新排序，这样可实现一个更有效的查询。下面就是这样一个例子：
- Sql代码
- Select * from authors
- Where state like "c%"
- Order by state
- Select * from authors
- Where state like "c%"
- Order by state
一般情况下，非聚集索引对单行查找（single-row lookup），连接（join），有高选择性的列的查询，小范围检索的查询有用。当你考虑非聚集索引的设计时也不要忽略了覆盖索引的优点，下节将会讲到。
索引覆盖（Index Covering）
索引覆盖是这样一种情况，查询中的select 和where子句中所需要的信息都能在非聚集索引中找到。因为非聚集索引包含了一个对应于表中每个数据行的一个叶子行，SQL Server能从非聚集索引的叶子行来满足查询。这导致了数据检索的更快，因为所有的信息能从索引页中直接获得，并且避免了SQL Server查找数据页。
因为非聚集索引的叶子页都连接在一起，索引的叶级可以像表中的数据页一样进行扫描，因为页级行都典型比数据行要小，一个覆盖了查询的非聚集索引将比同样列的聚集索引更快，因为需要读取的页数要更少。
在下面的例子中，quthors表中的关于au_lname 和au_fname的SQL Server非聚集索引将覆盖查询，因为结果中的列和SARG都能从索引中提取出来：
- Sql代码
- Select au_lname, au_fname
- From authors
- Where au_lname like "M%"
- GO
- Select au_lname, au_fname
- From authors
- Where au_lname like "M%"
- GO
其他使用聚合函数（MIN AVG SUM COUNT）的查询或者仅仅检查是否存在的查询也能从索引覆盖中获益。下面是一些能够利用索引覆盖优点的查询：
- Sql代码
- Select count (au_lname) from authors where au_lname like 'm%'
- Select count (*) from authors where au_lname like 'm%'
- Select count (*) from authors
- Select count (au_lname) from authors where au_lname like 'm%'
- Select count (*) from authors where au_lname like 'm%'
- Select count (*) from authors
你可能会奇怪最后一个查询，它甚至没有一个具体的SARG，怎么还能使用索引。SQL Server知道非聚集索引的特性，一个非聚集索引为表中的每行数据都包含了一行；它能够简单的计算任何一个非聚集索引的行数，而不需要扫描整个表。对最后一个查询，SQL Server选择最小的SQL Server非聚集索引——也就是，具有最少的叶子页的索引。
向非聚集索引添加列使得发生索引覆盖是一种提高查询响应时间的常见方法。考虑下面的查询：
- Sql代码
- Select royalty from titles
- Where price between $10 and $ 20
- Select royalty from titles
- Where price between $10 and $ 20
如果你仅在price列上创建索引，SQL Server能发现满足price在该范围的索引中的行，但是它还需要访问数据行来检索royalty。范围中有100行，最坏情况下检索数据所花费的IO代价计算如下：
引用
索引的级数
+查找匹配行的索引页的数
+100 * 每个书签查找页数
如果royalty列添加到了price列索引中了，索引能被扫描来检索结果，而不是进行书签查找，这样具有更快的查询响应。使用索引覆盖的IO代价将只是：
引用
索引级数
+查找匹配行的索引页的数
引用
注意：
当考虑添加索引来利用索引覆盖时，小心使得索引变得太宽。当索引行的宽度接近与数据行宽度时，覆盖的优点将失去，因为增加了叶级页的数目。当索引的叶级页的数目接近了表中页的数目，索引级数也增加了，那么索引扫描的时间就开始接近于表扫描时间了。
另外，如果你添加对到索引中的列频繁修改，数据行中列的任何修改也会波及到索引中。这增加了维护的负担，也会影响修改的性能。
正如第33章讨论的那样，当在一个表上创建了 一个聚集索引，聚集键会被所有的SQL Server非聚集索引引用，作为书签来定位实际的数据行。聚集键实际就是一些列，它们构成了聚集索引和它们的数据值。这种特性有时也能导致索引覆盖。
例如，假设suthors表在au_lname au_fname列上建立聚集索引，并有一个定义在au_id的非聚集索引。非聚集索引的每行都包含了与数据行对应的au_lname au_fname聚集键值。因为这个原因，下面查询将被非聚集索引覆盖：
- Sql代码
- select au_lname, au_fname
- from authors
- where au_id like '123%'
- select au_lname, au_fname
- from authors
- where au_id like '123%'
以上的相关内容就是对SQL Server非聚集索引（Noclustered Index Indications）的介绍，望你能有所收获。
【编辑推荐】
