聊一聊 SQLSERVER 的行不能跨页

一：背景

1. 讲故事

相信有很多朋友在学习 SQLSERVER 的时候都听说过这句话，但大多都是记忆为主，最近在研究 SQLSERVER，所以我们从 底层存储 的角度来深入理解下。

二：理解数据页

1. 数据页的组织

在前面的文章中我也说过，一个 数据页 是 8k 大小，那这 8k 是如何组织的呢？为了更好的表述，我先来画一张图，大概像下面这样。

从图中可以看到，一个数据页大概分为三部分：

页头

这一块相当于 数据页 的元数据区，标记着这个数据页类型和各种统计信息。

数据存储区

这里存放的就是表的每条记录以及记录的相关元数据，这个元数据统计着诸如定长，变长字段个数，记录类型等等。

记录槽位列表

slot 槽位记录了 行记录 在这个数据页上的偏移地址，过一会我们验证下即可，如果用 C++ 伪代码，大概是这样。



//行记录

struct _record

{

	char meta_s[8];

	int field1;

	char field2;

	short fieldn;

	char meta_e[8];

};

class page

{

private:

	char header[96];	 //1.页头

	_record records[n];	 //2. 行记录

	short slots[n];		 //3. 槽位 （指针由后向前）

};

2. 理解行的最大大小

相信大家从各种教科书中都能知道，我们能定义的最大行大小是 8060 byte，这包括行的 7byte 元数据大小，所以我们人肉能定义的大小只能是 8053byte，根据上一节的理解，这 8060byte 是落在 数据存储区 的，这里我们简单算一下页面是否刚好占满或者是否有保留区？接下来用一个公式简单算一下。



0:103> ? 0n8192 - 0n96 -0n2 - 0n8060

Evaluate expression: 34 = 00000000`00000022

上面的公式为： 保留大小 = 页面大小 - 页面头 - slot槽位 - 数据存储区，这么一算页面中还真有 34byte 的保留大小。

接下来我们简单验证下这个推理，首先自定义一行 8054byte 的大小看是否能通过？



USE MyTestDB

GO

CREATE TABLE t6 (a char(8000), b CHAR(54))

INSERT INTO t6 VALUES(REPLICATE('a',8000), REPLICATE('b',53))

从错误信息中可以清楚的看到，我的行记录总大小是 8061, 超过了系统规定的行记录大小8060。

接下来我们验证下 数据页 最小的保留大小是不是 34byte ？找到表数据页即可。



USE MyTestDB

GO

CREATE TABLE t6 (a char(8000), b CHAR(53))

INSERT INTO t6 VALUES(REPLICATE('a',8000), REPLICATE('b',53))

SELECT * FROM dbo.t6;

DBCC TRACEON(3604)

DBCC IND(MyTestDB,t6,-1)

从图中可以看到行记录是分配在 456 号 数据页上，接下来用 DBCC PAGE 观察一下。



DBCC PAGE(MyTestDB,1,456,2)

输出如下：

SQL Server 分析和编译时间:

   CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。

PAGE: (1:456)

BUFFER:

BUF @0x00000251CEB3F180

bpage = 0x00000251BCBE2000          bPmmpage = 0x0000000000000000       bsort_r_nextbP = 0x00000251CEB3F0D0

bsort_r_prevbP = 0x0000000000000000 bhash = 0x0000000000000000          bpageno = (1:456)

bpart = 0                           ckptGen = 0x0000000000000000        bDirtyRefCount = 0

bstat = 0x9                         breferences = 0                     berrcode = 0

bUse1 = 38957                       bstat2 = 0x0                        blog = 0x15ab215a

bsampleCount = 0                    bIoCount = 0                        resPoolId = 0

bcputicks = 0                       bReadMicroSec = 135                 bDirtyContext = 0x0000000000000000

bDbPageBroker = 0x0000000000000000  bdbid = 10                          bpru = 0x00000251CA5A0040

PAGE HEADER:

Page @0x00000251BCBE2000

m_pageId = (1:456)                  m_headerVersion = 1                 m_type = 1

m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8200

m_objId (AllocUnitId.idObj) = 193   m_indexId (AllocUnitId.idInd) = 256

Metadata: AllocUnitId = 72057594050576384

Metadata: PartitionId = 72057594043826176                                Metadata: IndexId = 0

Metadata: ObjectId = 1349579846     m_prevPage = (0:0)                  m_nextPage = (0:0)

pminlen = 8057                      m_slotCnt = 1                       m_freeCnt = 34

m_freeData = 8156                   m_reservedCnt = 0                   m_lsn = (37:1704:26)

m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt = 0

m_tornBits = 1904590527             DB Frag ID = 1                      

Allocation Status

GAM (1:2) = ALLOCATED               SGAM (1:3) = NOT ALLOCATED          PFS (1:1) = 0x44 ALLOCATED 100_PCT_FULL

DIFF (1:6) = CHANGED                ML (1:7) = NOT MIN_LOGGED           

DATA:

Memory Dump @0x000000E456778000

000000E456778000:   01010000 00820001 00000000 0000791f 00000000  ..............y.....

000000E456778014:   00000100 c1000000 2200dc1f c8010000 01000000  ........"...........

000000E456778028:   25000000 a8060000 1a000000 00000000 00000000  %...................

000000E45677803C:   bfbe8571 00000000 00000000 00000000 00000000  ...q................

000000E456778050:   00000000 00000000 00000000 00000000 1000791f  ..................y.

000000E456778064:   61616161 61616161 61616161 61616161 61616161  aaaaaaaaaaaaaaaaaaaa

...

000000E456779FCC:   62626262 62626262 62626262 62020000 00002121  bbbbbbbbbbbbb.....!!

000000E456779FE0:   21212121 21212121 21212121 21212121 21212121  !!!!!!!!!!!!!!!!!!!!

000000E456779FF4:   21212121 21212121 21216000                    !!!!!!!!!!`.

OFFSET TABLE:

Row - Offset

0 (0x0) - 96 (0x60)

刚才也说了，页面元数据占了 96byte，里面包含了各种统计信息，比如 m_freeCnt = 34 就是当前页面的剩余空间，这个和我们刚才的计算公式是保持一致的，这 34byte 就是页面末位默认的 0x21 填充符。

三：总结

其实从上面的分析中可以得出，数据页还是有 34byte 的保留空间的，可能是出于某些原因不想再塞了，当然也可以用 WinDbg 观察下源码逻辑，可以下一个 C++ 异常断点。



0:113> sxe eh

0:113> g

(6aec.6a20): C++ EH exception - code e06d7363 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

KERNELBASE!RaiseException+0x69:

00007ff8`f61b3e49 0f1f440000      nop     dword ptr [rax+rax]

0:020> k

 # Child-SP          RetAddr               Call Site

00 00000022`cddf7b80 00007ff8`dd2f6720     KERNELBASE!RaiseException+0x69

01 00000022`cddf7c60 00007ff8`bab85763     VCRUNTIME140!_CxxThrowException+0x90 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 75]

02 00000022`cddf7cc0 00007ff8`bab85339     sqldk!TurnUnwindAndThrowImpl+0x582

03 00000022`cddf81b0 00007ff8`bab8531b     sqldk!SOS_OS::TurnUnwindAndThrow+0x9

04 00000022`cddf81e0 00007ff8`bab84fca     sqldk!ex_raise2+0x56e

05 00000022`cddf8520 00007ff8`5cf2c056     sqldk!ex_raise+0xc3

06 00000022`cddf85a0 00007ff8`5cf2e54d     sqlmin!RaiseHoBtRowsizeError+0x156

07 00000022`cddf8600 00007ff8`5c33ac06     sqlmin!SECreateRowset+0x444

08 00000022`cddfa940 00007ff8`995632f8     sqlmin!DDLAgent::SECreateRowsets+0x2e0

...

从线程栈可以看到，逻辑是在 SECreateRowset() 方法中抛出了 RaiseHoBtRowsizeError() 异常，应该是一个常量 cmp 比较，留给大家研究吧。