索引键的唯一性(2/4):唯一与非唯一聚集索引

原文:索引键的唯一性(2/4):唯一与非唯一聚集索引

在上一篇文章里,我们讨论了堆表上唯一/非唯一非聚集索引。在SQL Server里没有聚集索引定义的叫堆表。当你在堆表上定义了一个聚集索引,你的表数据就会重组按聚集键的顺序进行物理存储,因为这个表叫做聚集表。这篇文章里,我想谈下唯一和非唯一聚集索引之间的区别,这2类聚集索引对存储的影响。

看这个文章之前,希望你对聚集索引有个基本的认识,并且知道堆表和聚集表之间的区别,还有当在表上定义了一个聚集索引,表里数据页是如何组织的(B树结构)。

我们从唯一聚集索引谈起。在SQL Server里你有很多方法去定义唯一聚集索引。第1个最简单的方法就是列上定义一个主键(PRIMARY KEY)约束。SQL Server通过在表上创建那列的唯一聚集索引来施行主键(PRIMARY KEY)约束。另外一个方法是通过CREATE CLUSTERED INDEX语句来常见唯一聚集索引——但当你不指定UNIQUE属性时,SQL Server默认是会为你创建非唯一的聚集索引!下列这段代码会创建Customers表,这个表结构和上篇文章一样,但这次我们在CustomerID列创建主键(PRIMARY KEY)约束。因此SQL Server会在表上创建唯一聚集索引,在叶子层里,数据页是按CustomerID列值排序的。

 1 -- Create a table with 393 length + 7 bytes overhead = 400 bytes
 2 -- Therefore 20 records can be stored on one page (8.096 / 400) = 20,24
 3 CREATE TABLE Customers
 4 (
 5    CustomerID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
 6    CustomerName CHAR(100) NOT NULL,
 7    CustomerAddress CHAR(100) NOT NULL,
 8    Comments CHAR(189) NOT NULL
 9 )
10 GO
11
12 -- Insert 80.000 records
13 DECLARE @i INT = 1
14 WHILE (@i <= 80000)
15 BEGIN
16    INSERT INTO Customers VALUES
17    (
18       'CustomerName' + CAST(@i AS CHAR),
19       'CustomerAddress' + CAST(@i AS CHAR),
20       'Comments' + CAST(@i AS CHAR)
21    )
22
23    SET @i += 1
24 END
25 GO

我们可以通过DBCC IND命令找出索引根页后(PageType为2,IndexLevel为2,即B树有3层:根和叶子层,PagePID为15359),就可以使用DBCC PAGE查看根页的内容。这里我的索引根页是15359。

1 TRUNCATE TABLE dbo.sp_table_pages
2 INSERT INTO dbo.sp_table_pages
3 EXEC('DBCC IND(ALLOCATIONDB, Customers, -1)')
4
5 SELECT * FROM dbo.sp_table_pages ORDER BY IndexLevel DESC

1 DBCC PAGE(ALLOCATIONDB, 1, 15359, 3)
2 GO

从上图里,我们可以看到每个索引记录包含聚集键,在这个例子是CustomerID列的值。

如果你从字节存储级别分析聚集索引记录的话,你会发现SQL Server这里使用下列字节信息:

  • 1 byte:状态位
  • n bytes:聚集键——这个例子里是4 bytes
  • 4 bytes:页ID(PageID)
  • 2 bytes:文件ID(FileID)

可以看出,聚集键的长度直接影响索引记录的长度。这就是说,你的聚集键长度越小,索引页上就可以存放更多的索引记录,因此你的聚集索引将更紧凑,查找更快,维护更容易。当你在你的聚集索引继续往下看时,你会发现所有中间层的索引结构和刚才的描述完全一样。这2层是没有任何区别的,除了索引叶子层,因为这层包含你实际逻辑排序的数据页。

现在我们来看看SQL Server里非唯一聚集索引,看看它们和唯一聚集索引的区别。为了演示这类索引,我重建了Customers表,并通过CREATE CLUSTERED INDEX语句在表上创建了非唯一聚集索引。

 1 DROP TABLE dbo.Customers
 2 -- Create a table with 393 length + 7 bytes overhead = 400 bytes
 3 -- Therefore 20 records can be stored on one page (8.096 / 400) = 20,24
 4 CREATE TABLE Customers
 5 (
 6    CustomerID INT NOT NULL,
 7    CustomerName CHAR(100) NOT NULL,
 8    CustomerAddress CHAR(100) NOT NULL,
 9    Comments CHAR(181) NOT NULL
10 )
11 GO
12
13 -- Create a non unique clustered index
14 CREATE CLUSTERED INDEX idx_Customers_CustomerID
15 ON Customers(CustomerID)
16 GO

最后,我插入80000条记录,这些记录的CustomerID列(聚集键)不再唯一:

 1 -- Insert 80.000 records
 2 DECLARE @i INT = 1
 3 WHILE (@i <= 20000)
 4 BEGIN
 5    INSERT INTO Customers VALUES
 6    (
 7       @i,
 8       'CustomerName' + CAST(@i AS CHAR),
 9       'CustomerAddress' + CAST(@i AS CHAR),
10       'Comments' + CAST(@i AS CHAR)
11    )
12    INSERT INTO Customers VALUES
13    (
14       @i,
15       'CustomerName' + CAST(@i AS CHAR),
16       'CustomerAddress' + CAST(@i AS CHAR),
17       'Comments' + CAST(@i AS CHAR)
18    )
19    INSERT INTO Customers VALUES
20    (
21       @i,
22       'CustomerName' + CAST(@i AS CHAR),
23       'CustomerAddress' + CAST(@i AS CHAR),
24       'Comments' + CAST(@i AS CHAR)
25    )
26
27    INSERT INTO Customers VALUES
28    (
29       @i,
30       'CustomerName' + CAST(@i AS CHAR),
31       'CustomerAddress' + CAST(@i AS CHAR),
32       'Comments' + CAST(@i AS CHAR)
33    )
34
35 SET @i += 1
36 END
37 GO

我们找下这个非唯一聚集索引的根页:

1 TRUNCATE TABLE dbo.sp_table_pages
2 INSERT INTO dbo.sp_table_pages
3 EXEC('DBCC IND(ALLOCATIONDB, Customers, -1)')
4
5 SELECT * FROM dbo.sp_table_pages ORDER BY IndexLevel DESC

我们再来看看根页的内容:

1 DBCC PAGE(ALLOCATIONDB, 1, 15359, 3)
2 GO

我们发现,SQL Server这里增加了UNIQUIFIER (key)的额外列。这列是SQL Server用来保证非唯一聚集键唯一。UNIQUIFIER (key)是4 bytes始于0的长整型值。当你有2条CustomerID值都是1380时,第1条的UNIQUIFIER为0,第2条的UNIQUIFIER值为1。但SQL Server只在索引的导航结构(高于叶子层的所有层)里保存UNIQUIFIER,即叶子层的UNIQUIFIER不为0。SQL Server只在非唯一聚集索引的导航结构里包含0值的UNIQUIFIER,这就是说导航结构里是不物理保存UNIQUIFIER的。在非唯一聚集索引里,唯一保存UNIQUIFIER的地方是在数据页,就是保存实际数据的地方。下图是我们聚集聚集索引里的中间层,你会看到UNIQUIFIER在这里是保存的。

1 DBCC PAGE(ALLOCATIONDB, 1, 15359, 3)
2 GO
3
4 DBCC PAGE(ALLOCATIONDB, 1, 14635, 3)
5 GO

最后我们看看数据页14633:

1 DBCC TRACEON(3604)
2 DBCC PAGE(ALLOCATIONDB, 1, 14633, 3) with tableresults
3 GO

我们来找4条CustomerID值为1的记录,看看UNIQUIFIER的值是多少(应该是0,1,2,3)。

因此唯一和非唯一聚集索引的区别是在数据页,因为当使用非唯一聚集索引时,SQL Server使用4 bytes长的UNIQUIFIER来保证它们唯一,要记住,在你定义非唯一聚集索引时,这个额外开销始终存在。

下面文章我们会详细分析下唯一聚集索引上,唯一和非唯一非聚集索引的区别。请继续关注! 

时间: 2024-10-31 05:49:50

索引键的唯一性(2/4):唯一与非唯一聚集索引的相关文章

索引键的唯一性(3/4):唯一聚集索引上的唯一和非唯一非聚集索引

原文:索引键的唯一性(3/4):唯一聚集索引上的唯一和非唯一非聚集索引 在上篇文章里,我讨论了唯一和非唯一聚集索引的区别.我们已经知道,SQL Server内部使用4 bytes的uniquifier来保证非唯一聚集索引行唯一.今天我们来看下唯一聚集索引上,唯一和非唯一非聚集索引的区别.当我们在表上定义PRIMARY KEY约束时,SQL Server会为我们创建唯一聚集索引:另外我们可以通过CREATE UNIQUE CLUSTERED INDEX语句在表上创建唯一聚集索引.下面的代码会创建c

索引键的唯一性(1/4):堆表上的唯一与非唯一非聚集索引的区别

原文:索引键的唯一性(1/4):堆表上的唯一与非唯一非聚集索引的区别 在这篇文章里,我想详细介绍下SQL Server里唯一与非唯一非聚集索引的区别.看这个文章前,希望你已经理解了聚集和非聚集索引的概念,还有在SQL Server里是如何使用的. 很多人对唯一和非唯一索引非聚集索引的认识都不是很清晰.事实上,SQL Server在存储上这2类索引有着本质的区别,这些区别会影响到索引占用空间的大小和索引的使用效率. 今天我们从SQL Server里的堆表(Heap table) ,它是没有聚集索引

索引键的唯一性(4/4):非唯一聚集索引上的唯一和非唯一非聚集索引

原文:索引键的唯一性(4/4):非唯一聚集索引上的唯一和非唯一非聚集索引 在上一篇文章里,我谈了唯一聚集索引上的唯一和非唯一非聚集索引的区别.在这篇文章里,我想谈下非唯一聚集索引上的唯一和非唯一聚集索引的区别.我们都知道,SQL Server内部把非唯一聚集索引当作唯一聚集索引处理的.如果你定义了一个非唯一聚集索引,SQL Server会增加叫做uniquifier到你的索引记录,它导致你聚集索引的导航结构(B树的非叶子层)里,每条索引行都要用到4 bytes的开销. 下列代码再次创建我们的Cu

聚集索引,非聚集索引,唯一索引,索引视图

聚集索引对于从表中检索一定范围的数据值非常有用.非聚集索引最适于检索特定行,而聚集索引最适于检索一定范围的行.但是,由于每个表只允许使用一个聚集索引,因此按照这个简单的逻辑来确定要创建哪种类型的索引并不总能成功.对于该问题有一个简单的物理原因.对于聚集索引 B 树结构的上部(非叶层),如果像对它们的非聚集索引部分那样组织,则聚集索引的底层由表的实际 8 KB 数据页组成.但这种情况有一个例外,那就是在视图的基础上创建聚集索引时.因为将在下面介绍索引视图,所以我们将讨论针对实际表创建的聚集索引.在

从性能的角度谈SQL Server聚集索引键的选择

简介 在SQL Server中,数据是按页进行存放的.而为表加上聚集索引后,SQL Server对于数据的查找就是按照聚集索引的列作为关键字进行了.因此对于聚集索引的选择对性能的影响就变得十分重要了.本文从旨在从性能的角度来谈聚集索引的选择,但这仅仅是从性能方面考虑.对于有特殊业务要求的表,则需要按实际情况进行选择. 聚集索引所在的列或列的组合最好是唯一的 这个原因需要从数据的存放原理来谈.在SQL Server中,数据的存放方式并不是以行(Row)为单位,而是以页为单位.因此,在查找数据时,S

SQLSERVER聚集索引和主键(Primary Key)的误区认识

很多人会把Primary Key和聚集索引搞混起来,或者认为这是同一个东西.这个概念是非常错误的. 主键是一个约束(constraint),他依附在一个索引上,这个索引可以是聚集索引,也可以是非聚集索引.  所以在一个(或一组)字段上有主键,只能说明他上面有个索引,但不一定就是聚集索引. 例如下面: 复制代码 代码如下: USE [pratice] GO CREATE TABLE #tempPKCL ( ID INT PRIMARY KEY CLUSTERED --聚集索引 ) --------

[20160711]索引键值在Btree索引块中的顺序3

[20160711]索引键值在B tree索引块中的顺序3.txt --上午测试索引键值在B tree索引块中的顺序,许多人认为是有序,主要是插入后再建立索引. --这样看到索引块里面的键值就是有序的. --今天测试一下,如果索引分裂后是否会排序呢?索引分裂有两种情况,前面测试leaf node 50-50 splits的情况. --继续测试leaf node 90-10 splits的情况. 测试看看. 1.环境: SCOTT@test01p> @ ver1 PORT_STRING      

[20160908]唯一索引与非唯一索引.txt

[20160908]唯一索引与非唯一索引.txt --唯一索引与非唯一索引的区别在于rowid信息在索引的位置,唯一索引rowid在row header(数据部分).而非唯一索引在最后. --但是具体的内部结构oracle如何识别呢?做一个简单探究,通过例子来说明: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ --

SQL Server 2008存储结构之非聚集索引

非聚集索引与聚集索引具有相同的 B 树结构,它们之间的显著差别在于以下两点: 基础表的数据行不按非聚集键的顺序排序和存储. 非聚集索引的叶层是由索引页而不是由数据页组成. 非聚集索引既可以建在堆表结构上也可以建在聚集索引表上:非聚集索引中的每个索引行都包含非聚集键值和行定位符.此定位符指向聚集索引或堆中包含该键值的数据行. 如果表是堆则行定位器是指向行的指针.该指针由文件标识符 (ID).页码和页上的行数生成.整个指针称为行 ID (RID). 如果表包含有聚集索引,则行定位器是行的聚集索引键.