《Pro SQL Server Internals, 2nd edition》CHAPTER 2 Tables and Indexes中的Clustered Indexes翻译

聚集索引

聚集索引指定表中数据的物理顺序，该顺序根据聚集索引键进行排序。表只能定义一个聚集索引。

假设您想要在带有数据的堆表上创建一个聚集索引。作为第一步(如图2-5所示)，SQLServer创建另一个数据副本，然后根据群集键的值对该副本进行排序。数据页链接在双链接列表中，其中每个页都包含指向链中下一页和上一页的指针。此列表称为索引的叶级别，它包含实际表数据。

 

页面上的排序顺序由插槽数组控制。页面上的实际数据未排序。

当叶级别由多个页面组成时，SQLServer开始构建索引的中间级别，如图2-6所示。

中间级别为每个叶级页存储一行。它存储两条信息：物理地址和它引用的页面索引键的最小值。唯一的例外是第一页上的第一行，SQL Server存储的是NULL而不是最小索引键值。通过这种优化，SQL Server在插入键值最低的表中的行时，不需要更新非叶级的行。

中间级别上的页面也链接到双链接列表。SQLServer会添加越来越多的中间级别，直到有一个级别只包含单个页面。这个级别称为根级别，它成为索引的入口点，如图2-7所示。

如您所见，索引总是有一个叶级别、一个根级别和零个或多个中间级别，唯一的例外是当索引数据适合于单个页面时。在这种情况下，SQLServer不会创建单独的根级页，索引只包含单个叶级页。

索引中的级别数量在很大程度上取决于行和索引键的大小。例如，4字节整数列上的索引在中间级别和根级别上每行需要13个字节。这13个字节由2字节的插槽数组条目、4字节的索引键值、6字节的页面指针和1字节的行开销组成，这是足够的，因为索引键不包含可变长度和空列。

因此，您可以容纳8，060字节/每行13字节=每页620行。这意味着，使用一个中间级别，您最多可以存储620*620=384，400个叶级页面的信息。如果数据行大小为200字节，则可以在每个叶级页面中存储40行，在索引中最多存储15，376，000行，只有三个级别。

向索引添加另一个中间级别将基本上涵盖所有可能的整数值。

在现实生活中，指数碎片化会减少这些数字。我们将在第6章讨论索引碎片。

SQLServer可以通过三种不同的方式从索引中读取数据。第一种是有序扫描。假设我们希望从dbo.Customers OrderbyCustomerId查询中运行SELECT名称。索引的叶级别上的数据已根据CustomerId列值进行排序。因此，SQLServer可以从第一页到最后一页扫描索引的叶级别，并按行的存储顺序返回这些行。

SQLServer从索引的根页开始，从中读取第一行。该行使用表中的最小键值引用中间页。SQLServer读取该页并重复该过程，直到找到叶级别的第一个页。然后，SQLServer开始逐行读取，在页面的链接列表中移动，直到所有行都被读取为止。图2-8说明了这一过程。

前面查询的执行计划显示了Ordered属性设置为true的ClusteringIndexScan操作符，如图2-9所示。

值得一提的是，有序扫描不需要ORDERBY子句，有序扫描只是意味着SQLServer根据索引键的顺序读取数据。

SQL Server可以在两个方向(向前和向后)浏览索引。但是，您必须记住一个重要的方面：SQLServer在向后索引扫描期间不使用并行性。

可以通过检查执行计划中的索引扫描或索引查找运算符属性来检查扫描方向。但是，请记住，ManagementStudio不会在执行计划的图形表示中显示这些属性。您需要打开“属性”窗口才能看到它，方法是在执行计划中选择操作符并选择“视图/属性”窗口菜单项或按F4键。

SQL Server的企业版有一个称为旋转木马扫描的优化功能，允许多个任务共享相同的索引扫描。假设您有会话S1，它正在扫描索引。在扫描过程中的某个时刻，另一个会话S2运行一个需要扫描相同索引的查询。通过旋转木马扫描，S2在其当前扫描位置加入S1。SQLServer只读取每页一次，将行传递给两个会话。

当S1扫描到索引的末尾时，S2从索引的开头开始扫描数据，直到S2开始扫描的位置。

旋转木马扫描是另一个例子，说明为什么不能依赖索引键的顺序，以及为什么在重要的时候应该总是指定ORDERBY子句。

顺序扫描之后的下一个访问方法称为分配顺序扫描。SQLServer通过IAM页访问表数据，类似于使用堆表的方式。带有(NOLOCK)查询的SELECT Name from dbo.Customers(NOLOCK)查询和图2-10说明了这种方法。图2-11显示了查询执行计划。

不幸的是，要检测SQLServer何时使用分配顺序扫描并不容易。尽管执行计划中的Ordered属性显示为false，但它指示SQL Server不关心是否按照索引键的顺序读取行，而不是使用分配顺序扫描。

分配顺序扫描可以更快地扫描较大的表，尽管它的启动成本较高。当表较小时，SQL Server不使用此访问方法。另一个重要的考虑因素是数据一致性。SQLServer不使用具有聚集索引的表中的转发指针，并且分配顺序扫描可能会产生不一致的结果。由于分页引起的数据移动，可以跳过或多次读取行。因此，SQLServer通常避免使用分配顺序扫描，除非它读取READ UNCOMMITED或SERIALIZABLE事务隔离级别中的数据。

我们将在第6章“索引碎片”中讨论页面拆分和碎片，并在第三部分“锁定、阻塞和并发”中讨论锁定和数据一致性。

最后一种索引访问方法称为索引查找。来自dbo.Customers的选择名称说明了该操作，其中CustomerId介于4到7之间的查询和图2-12说明了该操作。

为了从表中读取行的范围，SQLServer需要从范围中查找键值最小的行，即4。SQLServer从根页开始，其中第二行引用最小键值为350的页。它大于我们要查找的键值(4)，SQL Server读取根页上第一行引用的中间级别数据页(1：170)。

同样，中间页面将SQLServer引导到第一个叶级页面(1：176)。SQLServer读取该页，然后读取CustomerIds分别等于4和5的行，最后从第二页读取其余两行。

执行计划如图2-13所示。

正如您所猜测的，索引查找比索引扫描效率更高，因为SQLServer只处理行和数据页的子集，而不是扫描整个表。

从技术上讲，有两种索引查找操作。第一种称为单例查找，有时称为点查找，SQLServer在其中查找并返回一行。例如，可以考虑CustomerId=2谓词的位置。另一种类型的索引查找操作称为范围扫描，它要求SQL Server查找键的最小值或最大值，并扫描(向前或向后)一组行，直到它到达扫描范围的末尾。CustomerId在4和7之间的谓词将导致范围扫描。这两种情况都显示为执行计划中的索引查找操作。

正如您所猜测的，范围扫描完全有可能强制SQLServer处理索引中的大量甚至所有数据页。

例如，如果将查询更改为使用WHERE CustomerId>0谓词，则SQL Server将读取所有行/页，即使您在执行计划中显示了Index Seek运算符。您必须牢记这一行为，并在查询性能调优期间始终分析范围扫描的效率。

在关系数据库中有一个称为SARGable谓词的概念，它代表Searcharumentable。如果SQL Server可以利用索引查找操作(如果存在索引)，则谓词为SARGable。简而言之，当SQLServer可以隔离要处理的单个值或索引键值范围时，谓词是SARGable，从而限制了谓词计算期间的搜索。显然，使用SARGable谓词编写查询并尽可能利用索引查找是有益的。

SARGable谓词包括下列运算符：=、>；、>；=、<；=、IN、Between和Like(如果前缀匹配)。

非SARGable运算符包括not、<；>；、like(在无前缀匹配的情况下)和not in。

使谓词非SARGable的另一种情况是对表列使用函数或数学计算。SQLServer必须对其处理的每一行调用该函数或执行计算。幸运的是，在某些情况下，您可以重构查询以使此类谓词成为SARGable。表2-1显示了这方面的几个例子。

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

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

如图2-14所示，对于INTEGER参数，SQLServer扫描聚集索引，将varchar转换为每行的整数。在第二种情况下，SQLServer在开始时将整数参数转换为varchar，并使用效率更高的聚集索引查找操作。

注意联接谓词中的列数据类型。隐式或显式数据类型转换可能会显著降低查询的性能。

在Unicode字符串参数的情况下，您将观察到非常类似的行为。让我们运行清单2-8所示的查询。图2-15显示了这些语句的执行计划。

如您所见，对于varchar列，Unicode字符串参数是非SARGable。这是一个比表面上看起来要严重得多的问题。虽然很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为Unicode。因此，除非参数数据类型显式指定为varchar，否则SQLServer客户端库将为String对象生成Unicode(Nvarchar)参数。这使得谓词非SARGable，而且由于不必要的扫描，即使对varchar列进行了索引，也可能导致严重的性能问题。

始终在客户端应用程序中指定参数数据类型。例如，在ADO.NET中，使用Parameters.sql(“@ParamName”，SqlDbType.Varchar，<；size>；).value=Variable而不是Parameters.sql(“@ParamName”).value=Variable重载。在ORM框架中使用映射来显式地指定类中的非Unicode属性。

还值得一提的是，对于nvarcharUnicode数据列，varchar参数是SARGable。