【翻译】SQL Server索引进阶:第六级,标签

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介:

什么是标签

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

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

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

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

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

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

 

 
  1. CREATE NONCLUSTERED INDEX FK_ProductID_ModifiedDate 
  2. ON Sales.SalesOrderDetail(ProductID, ModifiedDate) 
  3. 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
710         01 Nov 2001       1            5.70       5.70      44484       2853
710         01 Nov 2001       1            5.70       5.70      44499       3006
710         01 Nov 2001       1            5.70       5.70      44523       3346
710         01 Nov 2001       1            5.70       5.70      44527       3400

710         01 Jun 2002       1            5.70       5.70      46365       10183
712         01 Jul 2001       1            5.19       5.19      43673       136
712         01 Jul 2001       1            5.19       5.19      43694       342
712         01 Aug 2001       1            5.19       5.19      43846       524
712         01 Aug 2001       1            5.19       5.19      43847       528

Page n-1:

712         01 Aug 2001       1            5.19       5.19      43851       567
712         01 Aug 2001       1            5.19       5.19      43863       672
712         01 Aug 2001       1            5.19       5.19      43871       735
712         01 Sep 2001       1            5.19       5.19      44074       1441
712         01 Sep 2001       1            5.19       5.19      44109       1729

 

哪一种更好

RID标签在表中查询行将更快速,但是索引可能会没有覆盖查询。索引键的标签在进行表查询的时候会较慢,但是增加了索引覆盖查询的可能性,通常会包含做JOIN时候对于外键的需要。

问题“哪一种跟好?”的答案是:都不好。在索引表的时候,最重要的决定是:表的聚集索引是什么?一旦建立了聚集索引(根据文章中的三条规则),你就不需要担心非聚集索引带来的影响,他们都会执行的很好。

结论

非聚集索引的入口由查询键列、包含列、标签组成。标签的值既可以是RID,也可以是聚集索引的键,这依赖于表是堆表还是聚集索引表。为表选择最好的聚集索引需要你依据三条规则,确保索引键是一个好的标签。

 




本文转自 virusswb 51CTO博客,原文链接:http://blog.51cto.com/virusswb/986374,如需转载请自行联系原作者

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
12天前
|
SQL 人工智能 算法
【SQL server】玩转SQL server数据库:第二章 关系数据库
【SQL server】玩转SQL server数据库:第二章 关系数据库
51 10
|
1月前
|
SQL 存储 数据库
sql事务、视图和索引
sql事务、视图和索引
14 0
|
22天前
|
SQL
启动mysq异常The server quit without updating PID file [FAILED]sql/data/***.pi根本解决方案
启动mysq异常The server quit without updating PID file [FAILED]sql/data/***.pi根本解决方案
17 0
|
12天前
|
SQL 算法 数据库
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(二)数据查询
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(二)数据查询
75 6
|
7天前
|
SQL 安全 网络安全
IDEA DataGrip连接sqlserver 提示驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接的解决方法
IDEA DataGrip连接sqlserver 提示驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接的解决方法
17 0
|
12天前
|
SQL 存储 数据挖掘
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
服务器数据恢复环境: 一台安装windows server操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。 在windows服务器内装有SqlServer数据库。存储空间LUN划分了两个逻辑分区。 服务器故障&初检: 由于未知原因,Sql Server数据库文件丢失,丢失数据涉及到3个库,表的数量有3000左右。数据库文件丢失原因还没有查清楚,也不能确定数据存储位置。 数据库文件丢失后服务器仍处于开机状态,所幸没有大量数据写入。 将raid5中所有磁盘编号后取出,经过硬件工程师检测,没有发现明显的硬件故障。以只读方式将所有磁盘进行扇区级的全盘镜像,镜像完成后将所
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
|
14天前
|
SQL 数据库 索引
SQL索引失效原因分析与解决方案
SQL索引失效原因分析与解决方案
22 0
|
16天前
|
SQL 数据安全/隐私保护
SQL Server 2016安装教程
SQL Server 2016安装教程
17 1
|
16天前
|
SQL 安全 Java
SQL server 2017安装教程
SQL server 2017安装教程
15 1
|
29天前
|
SQL 存储 Python
Microsoft SQL Server 编写汉字转拼音函数
Microsoft SQL Server 编写汉字转拼音函数