第九周翻译

聚集索引

聚集索引指示这张表数据的物理顺序，表是按聚集索引键来排序的。表中仅有一个唯一的聚集索引。让我们设想一下，如果你想使用堆表中的数据建立一个聚集索引。第一步，如图2-5所示，SQL Server创建数据的另一个副本，然后这些数据根据群聚值进行排序。数据页是链接到一个双链列表中，其中每个页面都包含指向链的下一个和前一个的指针。这个列表被称为索引的叶级，它包含表中实际的数据。

当叶级由多张页组成的时候，SQL Server开始建立索引的中间层，

中间层为每个叶级页面存储一行。它储存两条信息：一个是物理地址，另一个就是它所涉及的页中索引键的最小值。唯一特殊的就是再第一页的第一行，SQL Server储存的值为空而不是索引的最小值。有了这样的优化，当你插入表中最低键值的行时，SQL Server不需要更新没有叶级的行。在中间层的页面也是链接双链列表的。SQL Server添加越来越多的中间层直到其中的一个页面仅仅包含单个页面。这个级别被称为根级别，它成为索引的一个出口，如图2-7。

正如你所见，通常来说索引只有一个叶级，一个根级和一个或者多个中间层。唯一一个例外是索引数据适合于单个页面。在这个案例中，SQL Server不能创建单个分离的根级页面，并且索引仅仅由单个叶级页面组成。在索引中，叶级的数量很大程度上取决于行和索引键的量。例如，一个4字节为整型列的索引在中间层和根级每行需要13个字节。13个字节中，2个字节是slot数列入口，4字节索引键大的值，6字节页面指针和一个字节的行。结果，你能够积累8060个字节/每行13个字节，煤业620行。这个意思就是说，一个中间层大概可以储存620*620=384400叶级页面的信息。如果你的数据行大小是200字节，你可以在每个叶级页面储存400行，并且仅仅一个有三级的索引可以储存15376000行。在索引中增加另一个中间层大体上可以覆盖所有可能的整型的值。SQL Server从索引中读数据有三种方法。第一种是顺序扫描。让我们设想一下，如果我们要运行SELECT Name FROM dbo.Customers ORDER BY CustomerId 这条语句。在索引中的叶级的数据已经根据聚集列的值分类。结果，SQL Server可以从第一页到最后一页读取索引的叶级并且根据他们分类的顺序返回行。SQL Server从索引的根叶级开始并且从这开始读取第一行的数据。该行引用中间页，该页具有表中的最小键值。SQL Server读取该页面并重复该过程，直到在叶子级找到第一个页面。然后，SQL Server开始逐个读取行，遍历页面的链表直到所有行都被读取。图2-8说明了这个过程。

前面查询的执行计划显示了聚集索引扫描操作符，并将有序属性设置为true，如图2-9所示。

值得一提的是，order by子句不是触发有序扫描所必需的。有序扫描只意味着SQL Server根据索引键的顺序读取数据。SQL Server可以在索引中向前和向后两个方向导航。但是，您必须记住一个重要方面:SQL Server在向后索引扫描期间不使用并行性。SQL Server的企业版有一个优化特性称为旋转木马扫描，允许多个任务共享同一个索引扫描。假设有会话S1，他在扫描索引。在扫描过程中，另一个会话S2运行一个查询，该查询需要扫描相同的索引。使用旋转木马扫描，S2在当前扫描位置加入S1。SQL Server只读取每个页面一次，将行传递给两个会话。当S1扫描到达索引的末尾时，S2从索引的开始处开始扫描数据，直到S2扫描开始的地方。旋转木马扫描是另一个例子，说明了为什么不能依赖索引键的顺序，以及为什么在重要的时候应该始终指定order BY子句顺序扫描之后的下一个访问方法称为分配顺序扫描。SQL Server通过IAM页面访问表数据，类似于它对堆表的访问方式。从dbo中选择名称。使用(NOLOCK)查询的客户和图2-10说明了这种方法。图2-11显示了查询执行计划。

不幸的是，当SQL Server使用分配顺序扫描时，很难检测到。尽管执行计划中的Ordered属性显示为false，但它表明SQL Server并不关心是否按索引键的顺序读取行，而不关心是否使用了分配顺序扫描。分配顺序扫描可以更快地扫描大型表，尽管它的启动成本更高。当表很小时，SQL Server不使用这种访问方法。另一个重要的考虑因素是数据一致性。SQL Server在具有聚集索引的表中不使用转发指针，分配顺序扫描可能产生不一致的结果。由于页分割引起的数据移动，可以跳过或多次读取行。因此，SQL Server通常避免使用分配顺序扫描，除非它以READ UNCOMMITTED或SERIALIZABLE事务隔离级别读取数据。

为了从表中读取行范围，SQL Server需要从范围中找到键值最小的行，即4。SQL Server从根页面开始，其中第二行引用键值最小为350的页面。它大于我们正在寻找的键值(4)，SQL Server读取根页面第一行引用的中间层数据页(1:170)。类似地，中间页面将SQL Server引导到第一个叶级页面(1:176)。SQL Server读取该页，然后读取customerid为4和5的行，最后从第二页读取剩余的两行。执行计划如图2-13所示。

可以猜到，索引查找比索引扫描更有效，因为SQL Server只处理行和数据页的子集，而不是扫描整个表。从技术上讲，有两种索引查找操作。第一个称为单例查找，有时称为点查找，其中SQL Server查找并返回一行。您可以以CustomerId = 2谓词的位置为例。另一种索引查找操作称为范围扫描，它要求SQL Server查找键的最低值或最高值，并扫描(向前或向后)一组行，直到到达扫描范围的末尾。CustomerId位于4和7之间的谓词将导致范围扫描。这两种情况都显示为执行计划中的索引查找操作。正如您所猜测的，范围扫描完全有可能强制SQL Server处理大量甚至所有来自索引的数据页。例如，如果将查询更改为使用WHERE CustomerId > 0谓词，SQL Server将读取所有行/页，即使在执行计划中显示了索引查找操作符。您必须记住这种行为，并始终在查询性能调优期间分析范围扫描的效率。关系数据库中有一个概念叫做SARGable谓词，它代表S earch Arg ument able。如果SQL Server可以使用索引查找操作(如果存在索引)，则谓词是SARGable。简而言之，当SQL Server可以隔离要处理的单个值或索引键值范围时，谓词是SARGable，从而限制了谓词计算期间的搜索。显然，使用SARGable谓词编写查询并尽可能利用index seek是有益的。SARGable谓词包括以下操作符:=、>、>=、<、<=、IN、BETWEEN和LIKE(在前缀匹配的情况下)。非sargable操作符包括NOT、<>、LIKE(在非前缀匹配的情况下)和NOT in。使谓词不可sargable的另一种情况是使用函数或数学方法对表列进行计算。SQL Server必须调用该函数，或者为它处理的每一行执行计算。幸运的是，在某些情况下，您可以重构查询，使这些谓词可SARGable。表2-1显示了一些这样的例子。

另一个必须记住的重要因素是类型转换。在某些情况下，可以使用不正确的数据类型使谓词不可sargable。让我们创建一个带有varchar列的表，并用一些数据填充它，如清单2-6所示。

聚集索引键列被定义为varchar，尽管它存储整数值。现在，让我们运行两个select，如清单2-7所示，并查看执行计划。

可以看到，unicode字符串参数对于varchar列是不可sargable的。这是一个比看上去要大得多的问题。虽然很少以这种方式编写查询，如清单2-8所示，但是现在大多数应用程序开发环境都将字符串视为unicode。因此，SQL Server客户端库为字符串对象生成unicode (nvarchar)参数，除非参数数据类型被显式指定为varchar。这使得谓词不可sargable，而且由于不必要的扫描，即使索引了varchar列，也会导致性能下降。