【SqlServer】 理解数据库中的数据页结构
【SqlServer】 理解数据库中的数据页结构
这篇文章,我将会带你深入分析数据库中 数据页(Page) 的结构。通过这篇文章的学习,你将掌握以下知识点:
1. 查看一个 表/索引 占用了多少了页。
2. 查看某一页中存储了什么的数据。
3. 验证在数据库中用 GUID类型时用 newid() 生成的数据作为聚集索引时的缺陷。
首先需要清楚 页(Page) 和 盘区(Extent) 的概念。页是SQL Server中数据存储的基本单元,每一页的大小都是8K。而盘区是一组页的集合,每一个盘区都是由8个相邻的页组合而成的。
上面的这张图片引用自微软官方文档,它展示了页的基本结构。
一个盘曲是8个页的集合,所以每一个盘曲的大小就是64K。1M的数据就包含16个盘曲。 盘曲分为两种:
1. 统一区(Uniform):由单个对象所有。区中的所有 8 页只能由所属对象使用。
2. 混合区(Mixed):最多可由八个对象共享。区中八页的每页可由不同的对象所有。
除此之外,还需要了解一个概念,就是IAM页,它的全称是Index Allocation Map Page。IAM是对盘曲(Extent)的管理,每个IAM最大为4G。当数据超过4G时,或者IAM页中的 Extent 存储跨文件时,就会形成IAM链。
可以通过 sys.system_internals_allocation_units 来查看 一个分配单元(allocation unit)的第一个IAM页 地址。
IAM链的逻辑概念图:
上面只是简单地介绍了一下 页,区,和分配单元 的基本概念,更多信息,请查看 Pages and Extents Architecture Guide.
有了上面的基本概念后,接下来进行实际案例分析。
首先创建一个测试的数据库,并且插入一些测试数据。
CREATE DATABASE TESTGOUSE TESTCREATE TABLE DBO.EMPLOYEE ( EMPLOYEEID INT IDENTITY(1,1), FIRSTNAME VARCHAR(50) NOT NULL, LASTNAME VARCHAR(50) NOT NULL, DATE_HIRED DATETIME NOT NULL, IS_ACTIVE BIT NOT NULL DEFAULT 1, CONSTRAINT PK_EMPLOYEE PRIMARY KEY (EMPLOYEEID), CONSTRAINT UQ_EMPLOYEE_LASTNAME UNIQUE (LASTNAME, FIRSTNAME) )GOINSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'George', 'Washington', '1999-03-15'GOINSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'Benjamin', 'Franklin', '2001-07-05'GOINSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'Thomas', 'Jefferson', '2002-11-10'GO
现在,上面的表和索引已经成功创建了,并且SQL Server将这些数据以页的形式存起来了。我们可以通过DBCC IND命令来罗列出这些信息。
DBCC IND语法:
DBCC IND (['database name'|database id], -- the database to usetable name, -- the table name to list resultsindex id, -- an index_id from sys.indexes; -1 shows all indexes and IAMs, -2 just show IAMs)
接下来,让我们来看看 EMPLOYEE表的页信息:
-- List data and index pages allocated to the EMPLOYEE tableDBCC IND('Test',EMPLOYEE,-1)GO
输出结果:
字段解释,PageFID:文件编号。PagePID:文件里页的编号。IAMFID:IAM页所在文件的编号。IAMPID:IAM页在文件里的编号。ObjectID:对象编号,可以由OBJECT_NAME获得其名称。IndexID:是sys.indexes中的的index_id值,1是聚集索引,2是非聚集索引。PartitionNumber:分区数。PartitionID:分区编号。iam_chain_type:IAM链类型,IN_ROW DATA 表示用于存储堆分区或索引分区,每个堆和索引的分区都有IN_ROW DATA的分配单元。Page Type: 页类型,1是数据页,2是索引页,10是IAM页。IndexLevel:表示页所在树中的层级,0表示叶子节点。NextPageFID:下一个文件的编号。NextPagePID:下一个页编号。PrevPageFID:前一个文件的编号。PrevPagePID:前一个页编号。
有了这些信息后,我们进行进一步的分析。上面的EMPLOYEE表,有一个聚集索引为PK_EMPLOYEE,所以它的index_id就为1,并且PageType也应该为1(因为聚集索引就是实际存储数据的顺序)。因此我们可以锁定为上面的第2条数据,就可以得出PageFID和PagePID的值,有了这两个值后,我们就可以深入到页里面去观察了。使用DBCC PAGE命令,可以清楚地观察到页里面到底存了什么数据。
-- TRACEON(3604) 表示将结果输出到控制台-- 1 是 PageFID-- 368 是 PagePID-- 3 表示输出Header和Data信息DBCC TRACEON(3604)DBCC PAGE('Test',1,368,3) WITH TABLERESULTSGO
输出结果:
通过上面的结果图可以看出,数据是按照聚集索引的顺序存储的(EMPLOYEEID)。每一条数据都对应一个slot,slot从0开始,每次增加1,slot 0, slot 1, slot 2 ...... slot n。Field和Value字段,清楚地展示了我们所存储数据。每次的偏移(Offset)都是上次的 Offset 加上上一个字段的长度。
EMPLOYEE表除了聚集索引,还有一个非聚集索引(UQ_EMPLOYEE_LASTNAME)。由于非聚集索引的index_id的值为2, 并且PageType也应该为2,所以我们知道它的PagePID为1, PagePID为400,接下来看看页里的详细信息:
-- TRACEON(3604) 表示将结果输出到控制台-- 1 是 PageFID-- 400 是 PagePID-- 3 表示输出Header和Data信息DBCC TRACEON(3604)DBCC PAGE('Test',1,400,3) WITH TABLERESULTSGO
输出结果:
滑倒最下面,可以看到一张更清楚的索引逻辑表。
从这个表中可以清楚地看到非聚集索引是按照逻辑存储的。并且每条数据都又一个EMPLOYEEID,也就是主键。换句话说,在有聚集索引的表中,非聚集索引是通过主键和原始数据关联。这一点和堆表(heap table, 没有聚集索引的表)不一样。
上面观察了聚集索引和非聚集索引的页信息,除了这两个,还有一个是IAM页的信息,这里笔者不做过多描述。有兴趣的朋友,可以自己打印出来看看。打印方法和上面的一致。接下来我们再来看看堆表(heap table)中的索引页是如何存储的。
alter table EMPLOYEE drop constraint PK_EMPLOYEEGOALTER TABLE DBO.EMPLOYEE ADD CONSTRAINT PK_EMPLOYEE PRIMARY KEY NONCLUSTERED (EMPLOYEEID)GODBCC IND('Test',EMPLOYEE,-1)DBCC PAGE('Test',1,440,3)
输出结果:
我们可以看出堆表中的非聚集索引都有一个HEAP RID,它指向了实际的数据源。RID值的格式为 FileID:PageID:SlotID 组成,移步Heaps(Tables Without Clustered Indexes)获取详细信息。
通过上面的学习你已经知道表的数据页的存储结构了,然后,笔者解决一下最开始提出的问题。
1. 查看一个 表/索引 占用了多少了页 ?
可以通过命令DBCC IND输出所有的页信息,然后再通过NextPagePID来得出某一个索引的全部页。
2. 查看某一页中存储了什么的数据 ?
可以通过命令DBCC PAGE某一个页里存储的数据详情。
3. 验证在数据库中用 GUID类型时用 newid() 生成的数据作为聚集索引时的缺陷?
通常情况,将newid()作为聚集索引是非常不好的设计,使用如下的测试案例来评测一下将newid()作为聚集索引时的存储缺点。
USE TESTCREATE TABLE DBO.EMPLOYEE ( EMPLOYEEID [uniqueidentifier] not null default newid(), FIRSTNAME VARCHAR(50) NOT NULL, LASTNAME VARCHAR(50) NOT NULL, DATE_HIRED DATETIME NOT NULL, CONSTRAINT PK_EMPLOYEE PRIMARY KEY (EMPLOYEEID) )INSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'George', 'Washington', '1999-03-15'GOINSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'Benjamin', 'Franklin', '2001-07-05'GOINSERT INTO DBO.EMPLOYEE (FIRSTNAME,LASTNAME,DATE_HIRED)SELECT 'Thomas', 'Jefferson', '2002-11-10'
然后查看一下内存页的数据存储情况
DBCC IND('Test',EMPLOYEE,-1)DBCC TRACEON(3604)DBCC PAGE('Test',1,456,3) WITH TABLERESULTS
输出结果:
你会发现实际数据的存储顺序和插入数据的顺序不一致,也就是说在SQL Server在插入新数据时,可能会移动其它的数据(因为newid()每次生成的数据都是随机的),插入新数据时候,移动其它的数据无疑是一种额外的消耗,在大数据量的表中,缺陷尤其明显。
怎么解决这个问题呢? 有两个方法,第一是不用uniqueidentifier作为主键类型,第二种是使用这里 NEWSEQUENTIALID() 替换 NEWID() 。NEWSEQUENTIALID()每次生成的值都会比它以前生成的值大。
感谢读者耐心地阅读完本文,上面提到的 DBCC IND 和 DBCC PAGE命令,微软官方并没有提供相应的文档。未来,这些命令的功能可能会改变或是移除。目前笔者的数据库是2016的版本。本文参考了Armando Prato的Using DBCC PAGE to Examine SQL Server Table and Index Data文章,有兴趣的朋友,可以移步Armando Prato的博客查看更多内容。
来源https://www.cnblogs.com/HDK2016/p/15067191.html