《Pro SQL Server Internals》翻译2

Posted qq602199686

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《Pro SQL Server Internals》翻译2相关的知识,希望对你有一定的参考价值。

                                                                                     聚集索引

     

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

    假设您要在堆表上使用数据创建聚集索引。 作为第一步,如图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字节的行开销组成,这足够了,因为索引键不包含可变长度和空列。

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

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

SQL Server可以以三种不同的方式从索引读取数据。第一个是通过有序扫描。假设我们要运行SELECT Name from dbo.Customers ORDER BY.CustomerId query。索引的叶级数据已经基于CustomerId列值进行了排序。因此,SQL Server可以扫描索引从第一页到最后一页的叶子级别,并按照存储行的顺序返回行。

SQL Server从索引的根页开始,然后从那里读取第一行。该行引用表中具有最小键值的中间页。SQL Server读取该页面,并重复该过程,直到在叶级找到第一个页面。然后,SQL Server开始逐行读取,遍历页面的链接列表,直到所有行都被读取。图2-8说明了这个过程。

 

技术分享图片

                                                           图2-8. 有序索引扫描

 

     上述查询的执行计划显示了“集群索引扫描”运算符,其中Ordered属性设置为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子句。

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

 

 技术分享图片

                                                                         图2 - 10.分配顺序扫描

 

技术分享图片

 

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

 

 

不幸的是,当SQL Server使用分配顺序扫描时,检测起来并不容易。 即便如此执行计划中的有序属性显示为false,表示SQL Server不关心是否按索引键的顺序读取行,而不是使用分配顺序扫描。

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

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

       最后一个索引访问方法称为索引查找。 SELECT名称来自dbo.Customers WHERE CustomerId BETWEEN 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.索引查找执行计划

 

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

 

 技术分享图片

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

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

 

 

 

 1 create table dbo.Data
 2 
 3  
 4 
 5 (
 6 
 7  
 8 
 9  VarcharKey varchar(10) not null,
10 
11  
12 
13  Placeholder char(200)
14 
15  
16 
17 );
18 
19  
20 
21 create unique clustered index IDX_Data_VarcharKey
22 
23  
24 
25 on dbo.Data(VarcharKey);
26 
27  
28 
29 ;with N1(C) as (select 0 union all select 0) -- 2 rows
30 
31  
32 
33 ,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows
34 
35  
36 
37 ,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows
38 
39  
40 
41 ,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows
42 
43  
44 
45 ,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows
46 
47  
48 
49 ,IDs(ID) as (select row_number() over (order by (select null)) from N5)
50 
51  
52 
53 insert into dbo.Data(VarcharKey)
54 
55  
56 
57  select convert(varchar(10),ID) from IDs;

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

 

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

 

 

 

 

 

1 declare
2 
3 @IntParam  int  =  200
4 
5 select  *  from  dbo.Data  where  VarcharKey  =  @IntParam;
6 
7 select  *  from  dbo.Data  where  VarcharKey  =  convert(varchar(10),@IntParam);

 

 

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

 

技术分享图片

 

 

 

 

图2-15。 SARG谓词和数据类型:带字符串参数的执行计划

如您所见,对于varchar列,unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询,如清单2-8所示,但现在大多数应用程序开发环境都将字符串视为unicode。 因此,除非参数数据,否则SQL Server客户端库会为字符串对象生成unicode(nvarchar)参数type显式指定为varchar。 这使得谓词不具有SARG,并且由于不必要的扫描,它可能导致主要的性能命中,即使对varchar列进行索引也是如此。

)。Value=stringVariable而不是Parameters.Add("@ParamName")。Value=stringVariable重载。在ORM框架中使用映射来显式地指定类中的非Unicode属性。" >重要的是始终在客户端应用程序中指定参数数据类型。例如,在ADO.Net中,使用Parameters.Add("@ParamName)、SqlDbType.Varchar、<Size>)。Value=stringVariable而不是Parameters.Add("@ParamName")。Value=stringVariable重载。在ORM框架中使用映射来显式地指定类中的非Unicode属性。

还值得一提的是,VARCHAR参数对于NVARCHAR Unicode数据列是可处理的

综合指数

具有多个键列的索引称为复合(或复合)索引。复合索引中的数据按每列从最左到最右的列进行排序。图2-16显示了复合索引的结构。

 

以上是关于《Pro SQL Server Internals》翻译2的主要内容,如果未能解决你的问题,请参考以下文章

《Pro SQL Server Internals》部分翻译

《Pro SQL Server Internals》翻译2

《Pro SQL Server Internals》部分翻译

《Pro SQL Server internals》翻译

《Pro SQL Server Internals》翻译之索引

《Pro SQL Server Internals》翻译3