SQL Server索引进阶：第六级，标签-白红宇

SQL Server索引进阶：第六级，标签

阅读量：4962 次

发布时间：2019-06-12

本文共 4592 字，大约阅读时间需要 15 分钟。

原文地址：

本文是SQL Server索引进阶系列（）的一部分。

在前面的章节中我们看到了，索引就是一些有序入口的集合，每行一个入口。我们更多的强调索引的逻辑方面，而不是物理方面。当目前为止，我们讲述了非聚集索引入口的两个组件：查询键和包含列。在本章中，我们介绍第三个，也是最后一个组件：标签。

什么是标签

标签在之前已经提到过，但只是说SQL Server可以用它快速的从非聚集索引的入口导航到对应的行。现在，是时候介绍更多的细节了。标签的内容会根据表示表示堆表还是聚集索引表，而不同。

不管表是堆表还是聚集索引表，表中的每一行都会位于页的一行。页可能是数据文件的第n页。文件可能是组成数据库的文件集合中的第n个文件。因此，数据库中的每一行，在任何时间，都可以用三个数字来标识：文件号-页号-行号。这三个数字的复合标识叫做rowid，通常叫做RID。大部分可以显示SQL Server内部信息的工具都会显示这三个号码，用分号分隔。因此文件1的77页的12行，RID会显示成1:77:12。

通常来讲，一个堆表的行是不会移动的，一旦他们被插入一页，他们会保持在这页中。更加精准的说法是：在堆表中的行很少移动，当他们移动的时候，在旧的位置上会留下新的地址。聚集索引表的行，是可以移动的，在修改数据或者是维护索引的时候可能会分配到另外一页。在修改数据的时候发生的细节，还有新行的信息，都会在后面的级别中介绍。

因为堆表的行不会移动，在堆表中RID永久的标识每一行。不仅值是永久的，而且物理位置也是永久的。因此在堆表的非聚集索引中，使得它成为理想的标签值，这也是SQL Server在所有的堆表的所有非聚集索引中使用它的原因。

一个堆表的非聚集索引：RID为基础的标签

SalesOrderDetail表是一个堆表，行没有特定的顺序。我们创建一个第五级中介绍的索引，在ProductID和ModifiedDate上的非聚集索引，而且还有包含列。

CREATE NONCLUSTERED INDEX FK_ProductID_ModifiedDate ON Sales.SalesOrderDetail(ProductID, ModifiedDate) INCLUDE (OrderQty, UnitPrice, LineTotal)

入口的顺序是下面的样子。

:- Key Columns -: :--- Included Columns ---: : Bookmark :

ProductID ModifiedDate OrderQty UnitPrice LineTotal

----------- ------------ -------- --------- --------- -------------

Page n-1:

709 01 Feb 2002 1 5.70 5.70 3:9198:41

709 01 May 2002 1 5.70 5.70 3:969:2

710 01 Jul 2001 1 5.70 5.70 3:9840:29

710 01 Jul 2001 1 5.70 5.70 3:9916:29

710 01 Sep 2001 1 5.70 5.70 4:12331:32

Page n:

710 01 Oct 2001 1 5.70 5.70 3:1911:33

710 01 Nov 2001 1 5.70 5.70 4:2604:34

710 01 Nov 2001 1 5.70 5.70 4:2889:34

710 01 Nov 2001 1 5.70 5.70 3:3522:35

710 01 Nov 2001 1 5.70 5.70 3:3623:35

710 01 Jun 2002 1 5.70 5.70 4:3917:5

712 01 Jul 2001 1 5.19 5.19 3:9886:29

712 01 Jul 2001 1 5.19 5.19 3:10270:29

712 01 Aug 2001 1 5.19 5.19 4:10609:30

712 01 Aug 2001 1 5.19 5.19 4:10617:30

Page n+1:

712 01 Aug 2001 1 5.19 5.19 4:10689:30

712 01 Aug 2001 1 5.19 5.19 4:10885:30

712 01 Aug 2001 1 5.19 5.19 4:11002:30

712 01 Sep 2001 1 5.19 5.19 4:12318:32

712 01 Sep 2001 1 5.19 5.19 4:509:32

索引中每一行的标签都是很有效的，直接指向对应的数据行，但是这需要依赖于表是否堆表。尽管这些值对于查询行非常有效，但是他们不包含用户需要的任何信息。

这种RID为基础的标签的替代者是，在已经有聚集索引的表上建立非聚集索引，简洁并准确的说，这种标签就是一种聚集索引的非聚集索引标签。

聚集索引的非聚集索引：键为基础的标签

如果一张表包含聚集索引，表中的行会被重新定位。因此，对于聚集索引来说，RID不是行的永久标识，非聚集索引的标签值需要使用一个不同的值。这个值就是聚集索引的索引键。

这解决了标签值一致性的需要。因为当聚集索引的一行被移动到新页的时候，它只是被移动，而没有被修改。聚集索引的键值没有改变。因此，标签的值总是可以用来获取对应的行，这意味着是通过聚集索引获取行，而不是通过物理位置获取行。

但是，这种聚集索引的键作为非聚集索引的标签的用法，意味着聚集索引的键应该满足三个条件：

它必须是唯一的。每个索引入口的标签，都是SQL Server用来查找入口对应的一行数据的。如果你创建的聚集索引不唯一，SQL Server就需要为重复的键创建额外的信息。这些SQL Server创建的额外信息被叫做“uniquifier”，对客户端应用来说是透明的。对于是否允许重复的聚集索引，你应该很小心的考虑下面两个因素：

它应该很短小。它应该占用少量的字节，因为它将被所有的非聚集索引包含。将表Contact的last name/first name/middle name/street address作为聚集索引的列看起来是个好主意，但是如果表Contact有多个非聚集索引，这就不是一个好主意了。如果包含n个非聚集索引，那么last name/first name/middle name/street address的信息就会保存n+1份。

它应该是静态的。它的值应该很少改变。聚集索引键值的改变，会导致每一个非聚集索引中对应行的入口发生更新操作。因此，如果一张表有n个非聚集索引，一次索引键的更新，会变成n+1次的更新。

AdventureWorks设计团队为SalesOrderDetail表选择聚集索引的时候，他们坚持了上面的三条原则。选择SalesOrderID/SalesOrderDetailID作为聚集索引的键，它们短小、静态，并且唯一。把SalesOrderID左右键的左列，尽管SalesOrderDetailID列本身就是唯一的，还是一起作为聚集索引的键。单个订单的所有行都会在相同的页，或者是两页。把SalesOrderID和SalesOrderDetailID即作为表的主键，又作为聚集索引键，消除了在SalesOrderDetailID列单独做索引的需求。没有人会要求查看#7行，他们会查看订单#47386的所有item，或者是订单#47386的#7 item。最重要的，我们已经说过很多次了，将表保持一个顺序，可以对应用提供最好的服务。

现在，如果我们在包含聚集索引的SalesOrderDetail表上创建相同的非聚集索引，索引入口的排序可能就是下面的样子。

:- Key Columns -: : --- Included Columns ---: :--- Bookmark ---:

ProductID ModifiedDate OrderQty UnitPrice LineTotal OrderId DetailId

----------- ------------ -------- --------- --------- ----------- ----------

Page n-1:

709 01 Feb 2002 1 5.70 5.70 45329 6392

709 01 May 2002 1 5.70 5.70 46047 8601

710 01 Jul 2001 1 5.70 5.70 43670 111

710 01 Jul 2001 1 5.70 5.70 43676 152

710 01 Sep 2001 1 5.70 5.70 44075 1448

Page n:

710 01 Oct 2001 1 5.70 5.70 44303 2481