翻译：聚集索引《Pro SQL Server Internals, 2nd edition》

最新推荐文章于 2019-05-09 15:21:01 发布

我不叫草稿纸

最新推荐文章于 2019-05-09 15:21:01 发布

阅读量197

点赞数

译文：《Pro SQL Server Internals, 2nd edition》
作者：Dmitri Korotkevitch
翻译：刘琼滨

译文：

聚集索引

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

让我们假设您希望在堆表上使用数据创建集群索引。作为第一步，如图2-5所示，SQL Server创建数据的另一个副本，然后根据集群键的值对其进行排序。数据页在双链表中链接，其中每个页面都包含指向链中的下一个和上一个页面的指针。这个列表称为索引的叶级，它包含实际的表数据。
在这里插入图片描述

图2 - 5.聚集索引结构:叶级

■注意页面上的排序顺序是由槽阵列控制。页面上的实际数据没有排序。

当叶子层包含多个页面时，SQL Server开始构建索引的中级维护，如图2-6所示。
在这里插入图片描述
图2 - 6.聚类索引结构:中间维护级和叶级

中间维护级为每个叶级页面存储一行。它存储了两条信息:物理地址和它引用的页面索引键的最小值。唯一的例外是第一页的第一行，其中SQL Server存储NULL，而不是最小索引键值。在这样的优化下,当您插入表中键值最低的行时，SQL Server不需要更新非叶级行。

中间维护级上的页面也链接到双链表。SQL Server添加了越来越多的中间级别，直到有一个级别只包含单个页面。这一层称为根层，它为索引的入口点，如图2-7所示。
在这里插入图片描述
图2-7.聚集索引结构:根级别

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

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

因此，每行可以容纳8060字节/ 13字节=每页620行。这意味着，使用一个中间层，可以存储最多620 * 620 = 384,400页的信息。如果数据行大小为200字节，那么每个叶级页面可以存储40行，索引中最多可以存储15,376,000行，其中只有三个级别。向索引中添加另一个中间级别将基本上覆盖所有可能的整数值。

■注意在现实生活中,索引碎片将减少这些数字。我们将在第六章讨论索引碎片

SQL Server可以通过三种不同的方式从索引读取数据。第一个是有序扫描。让我们假设希望从dbo运行SELECT名称。客户通过CustomerId查询下单。索引页级别上的数据已经根据CustomerId列值排序。因此，SQL Server可以从第一个页面扫描到最后一个页面的索引叶级别，并按照存储它们的顺序返回行。

SQL Server从索引的根页面开始，从根页面读取第一行。该行引用中间页，其中包含来自表的最小键值。SQL Server读取该页面并重复该过程，直到找到叶子级别上的第一个页面。然后，SQL Server开始逐个读取行，遍历页面的链表，直到读取了所有行。图2-8说明了这个过程。
在这里插入图片描述
图 2 - 8.排序索引扫描

前面查询的执行计划显示了集群索引扫描操作符，其有序属性设置为true，如图2-9所示。
在这里插入图片描述
图 2 - 9.排序索引扫描执行计划

值得一提的是，order by子句不需要触发有序扫描。有序扫描意味着SQL Server根据索引键的顺序读取数据。

SQL Server可以在前进和后退两个方向上导航索引。但是，您必须记住一个重要的方面:SQL Server在向后索引扫描期间不使用并行性。

■提示你可以检查扫描方向通过检查索引扫描或索引寻求运营商属性执行计划。但是请记住，Management Studio不会在执行计划的图形表示形式中显示这些属性。您需要打开Properties窗口，通过在执行计划中选择操作符并选择View/Properties窗口菜单项或按F4键来查看它。

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

当S1扫描到达索引的末尾时，S2从索引的开头开始扫描数据，直到S2扫描开始的那一点。旋转木马扫描是另一个例子，说明为什么不能依赖索引键的顺序，以及为什么在重要的时候应该始终指定order BY子句。

排序扫描之后的下一个访问方法称为分配顺序扫描。QL服务器通过IAM页面访问表数据，这与它通过堆表访问表数据的方式类似。从dbo中选择的名称。具有(NOLOCK)查询的客户和图2-10演示了这种方法。图2-11显示了查询执行计划。
在这里插入图片描述
图2 - 10.分配顺序扫描

图2 - 11.分配顺序扫描执行计划

不幸的是，SQL Server在使用分配顺序扫描时不容易检测到。如果执行计划中的Ordered属性为false，则表示SQL Server并不关心是否按照索引键的顺序读取行，也不关心是否使用了分配顺序扫描。

分配顺序扫描可以更快地扫描大型表，尽管它有较高的启动成本。当表很小时，SQL Server不使用这种访问方法。另一个重要的考虑因素是数据一致性。SQL Server在具有集群索引的表中不使用转发指针，分配顺序扫描可能产生不一致的结果。由于页面分割导致的数据移动，可以多次跳过或读取行。因此，SQL Server通常避免使用分配顺序扫描，除非它在未提交或可序列化事务隔离级别读取数据。

■注意我们将讨论页面分裂和分化在第六章,“索引碎片,”和在第三部分讨论锁定和数据一致性,“锁定、阻塞和并发性”。

最后一种索引访问方法称为索引寻道。从dbo中选择的名称。其中CustomerId在4到7之间的查询和图2-12说明了操作。
在这里插入图片描述
图2 - 12.索引查找

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

类似地，中间页面将SQL Server引导到第一个叶级页面(1:176)。SQL Server读取该页面，然后读取定制id为4和5的行，最后从第二个页面读取剩下的两行。

执行计划如图2-13所示。
在这里插入图片描述
图2 - 13.索引查找执行计划

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

从技术上讲，有两种索引查找操作。第一个称为单例查找，有时也称为点查找，SQL Server在其中查找并返回一行，以WHERE CustomerId = 2 为例；另一种类型的索引查找操作称为范围扫描，它使SQL服务器找到键的最大和最小值并扫描（前向后向扫描）行的集合直到到达扫描范围的末端。查询语句”WHERE CustomerId BETWEEN 4 AND 7 “进行范围扫描。这两种情况都显示为执行计划中的索引查找操作。

正如你所猜测的，范围扫描完全有可能强制SQL Server处理来自索引的大量甚至所有数据页。例如你改变查询命令为 WHERE CustomerId > 0，SQL服务器会读取所有页所有行，尽管能用索引查找显示执行计划，还是要记得在查询语句性能调节时，分析范围扫描的效率。SQL Server将读取所有行/页，即使在执行计划中显示了索引查找操作符。要记得在查询语句性能调节时，分析范围扫描的效率。

关系数据库有一个概念叫 SARGable 预测，代表搜索参数，这个预测是SARGable当SQL服务器能耐隔离出单独值或范围的索引键值时，在预测评价时限制查询。显然，SARGable预测还有利用索引查找对写查询语句很有利。

SARGable 预测包括这些操作符号：= , > , >= , < , <= , IN , BETWEEN , LIKE（防止前置匹配）。非SARGable操作符包括：NOT , <> , LIKE（防止非前置匹配）,NOT IN。

非SARGable预测时的另一种情况是使用功能或数学计算与表中的列产生冲突，sql服务器必须调用该函数或对其处理的每行执行计算。幸运的是，在某些情况下您可以重构查询来预测SARgable。表2-1列举了一些例子。
在这里插入图片描述
表2 - 1.重构不可SARGable谓词到可SARGable谓词的示例

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

清单2 - 6。SARG谓词和数据类型:测试表的创建

     create table dbo.Data
     (
         VarcharKey varchar(10) not null,
         Placeholder char(200)
     );
    create unique clustered index IDX_Data_VarcharKey
    on dbo.Data(VarcharKey);
    ;with N1(C) as (select 0 union all select 0) -- 2 rows
    ,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows
    ,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows
   ,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows
   ,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows
   ,IDs(ID) as (select row_number() over (order by (select null)) from N5
    insert into dbo.Data(VarcharKey)
    select convert(varchar(10),ID) from IDs;

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

清单2 - 7日.SARG谓词和数据类型:使用整型参数进行选择

    declare
       @IntParam int = '200'
    select * from dbo.Data where VarcharKey = @IntParam;
    select * from dbo.Data where VarcharKey = convert(varchar(10),@IntParam);

如图2-14所示，对于integer参数，SQL Server扫描集群索引，将varchar转换为每一行的整数。在第二种情况下，SQL Server在开始时将整型参数转换为varchar，并使用更高效的集群索引查找操作。
在这里插入图片描述
图2 - 14.SARG预测和数据类型:带有整型参数的执行计划

■提示：注意加入预测的列数据类型。隐式或显式数据类型转换会显著降低查询的性能。

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

清单2 - 8.SARG谓词和数据类型:使用字符串参数进行选择

    select * from dbo.Data where VarcharKey = '200';
    select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter

在这里插入图片描述
图2-15.S ARG预测和数据类型:带有字符串参数的执行计划

正如您所看到的，Unicode字符串参数对于varchar列是非SARGable 。这是一个比表面看来更大的问题。虽然很少用这种方式写查询语句，如表2-8，现在大多数应用程序开发环境将字符串视为Unicode。Sql服务器客户端库对于字符串对象产生Unicode（nvarchar）参数，除非参数数据类型明确指定为可变长字符型.使预测非SARGable，而且由于不必要的扫描，它会导致主要的性能命中即使是在可变长字符型列被索引的时候。

**■重要提示：在客户机应用程序指定参数的数据类型。**例如，在ADO中。使用SqlDbType Parameters.Add (“@ParamName”.Varchar、<大小>).Value = stringVariable而不是Parameters.Add (“@ParamName”)…Value = stringVariable重载。在ORM框架中使用映射显式地指定类中的非unicode属性。

值得一提的是可变长字符类型参数可用于nvarchar Unicode数据列