聊一聊 SQLSERVER 的行不能跨页

开发 前端
相信有很多朋友在学习 SQLSERVER 的时候都听说过这句话,但大多都是记忆为主,最近在研究 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 比较,留给大家研究吧。

责任编辑:武晓燕 来源: 一线码农聊技术
相关推荐

2023-03-07 15:58:31

云数据库云存储

2023-07-06 13:56:14

微软Skype

2020-09-08 06:54:29

Java Gradle语言

2023-09-22 17:36:37

2020-05-22 08:16:07

PONGPONXG-PON

2021-01-28 22:31:33

分组密码算法

2021-08-01 09:55:57

Netty时间轮中间件

2024-10-28 21:02:36

消息框应用程序

2023-09-27 16:39:38

2018-06-07 13:17:12

契约测试单元测试API测试

2021-03-01 18:37:15

MySQL存储数据

2021-12-06 09:43:01

链表节点函数

2023-09-20 23:01:03

Twitter算法

2021-07-16 11:48:26

模型 .NET微软

2023-05-15 08:38:58

模板方法模式

2022-08-08 08:25:21

Javajar 文件

2019-02-13 14:15:59

Linux版本Fedora

2018-11-29 09:13:47

CPU中断控制器

2021-02-06 08:34:49

函数memoize文档

2021-08-04 09:32:05

Typescript 技巧Partial
点赞
收藏

51CTO技术栈公众号