相信有很多朋友在學(xué)習(xí) SQLSERVER 的時(shí)候都聽(tīng)說(shuō)過(guò)這句話，但大多都是記憶為主，最近在研究 SQLSERVER，所以我們從 底層存儲(chǔ) 的角度來(lái)深入理解下。
?一：背景
1. 講故事
相信有很多朋友在學(xué)習(xí) SQLSERVER 的時(shí)候都聽(tīng)說(shuō)過(guò)這句話，但大多都是記憶為主，最近在研究 SQLSERVER，所以我們從 底層存儲(chǔ) 的角度來(lái)深入理解下。
二：理解數(shù)據(jù)頁(yè)
1. 數(shù)據(jù)頁(yè)的組織
在前面的文章中我也說(shuō)過(guò)，一個(gè) 數(shù)據(jù)頁(yè) 是 8k 大小，那這 8k 是如何組織的呢？為了更好的表述，我先來(lái)畫(huà)一張圖，大概像下面這樣。
從圖中可以看到，一個(gè)數(shù)據(jù)頁(yè)大概分為三部分：
頁(yè)頭
這一塊相當(dāng)于 數(shù)據(jù)頁(yè) 的元數(shù)據(jù)區(qū)，標(biāo)記著這個(gè)數(shù)據(jù)頁(yè)類型和各種統(tǒng)計(jì)信息。
數(shù)據(jù)存儲(chǔ)區(qū)
這里存放的就是表的每條記錄以及記錄的相關(guān)元數(shù)據(jù)，這個(gè)元數(shù)據(jù)統(tǒng)計(jì)著諸如定長(zhǎng)，變長(zhǎng)字段個(gè)數(shù)，記錄類型 等等。
記錄槽位列表
slot 槽位記錄了 行記錄 在這個(gè)數(shù)據(jù)頁(yè)上的偏移地址，過(guò)一會(huì)我們驗(yàn)證下即可，如果用 C++ 偽代碼，大概是這樣。
//行記錄
struct _record
{
char meta_s[8];
int field1;
char field2;
short fieldn;
char meta_e[8];
};
class page
{
private:
char header[96]; //1.頁(yè)頭
_record records[n]; //2. 行記錄
short slots[n]; //3. 槽位 （指針由后向前）
};
2. 理解行的最大大小
相信大家從各種教科書(shū)中都能知道，我們能定義的最大行大小是 8060 byte?，這包括行的 7byte? 元數(shù)據(jù)大小，所以我們?nèi)巳饽芏x的大小只能是 8053byte?，根據(jù)上一節(jié)的理解，這 8060byte? 是落在 數(shù)據(jù)存儲(chǔ)區(qū) 的，這里我們簡(jiǎn)單算一下頁(yè)面是否剛好占滿或者是否有保留區(qū)？接下來(lái)用一個(gè)公式簡(jiǎn)單算一下。
0:103> ? 0n8192 - 0n96 -0n2 - 0n8060
Evaluate expression: 34 = 00000000`00000022
上面的公式為：保留大小 = 頁(yè)面大小 - 頁(yè)面頭 - slot槽位 - 數(shù)據(jù)存儲(chǔ)區(qū)?，這么一算頁(yè)面中還真有 34byte 的保留大小。
接下來(lái)我們簡(jiǎn)單驗(yàn)證下這個(gè)推理，首先自定義一行 8054byte 的大小看是否能通過(guò)？
USE MyTestDB
GO
CREATE TABLE t6 (a char(8000), b CHAR(54))
INSERT INTO t6 VALUES(REPLICATE('a',8000), REPLICATE('b',53))
從錯(cuò)誤信息中可以清楚的看到，我的行記錄總大小是 8061?, 超過(guò)了系統(tǒng)規(guī)定的行記錄大小8060。
接下來(lái)我們驗(yàn)證下 數(shù)據(jù)頁(yè)? 最小的保留大小是不是 34byte ？找到表數(shù)據(jù)頁(yè)即可。
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 號(hào)? 數(shù)據(jù)頁(yè)上，接下來(lái)用 DBCC PAGE 觀察一下。
DBCC PAGE(MyTestDB,1,456,2)
輸出如下：
SQL Server 分析和編譯時(shí)間:
CPU 時(shí)間 = 0 毫秒，占用時(shí)間 = 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)
剛才也說(shuō)了，頁(yè)面元數(shù)據(jù)占了 96byte?，里面包含了各種統(tǒng)計(jì)信息，比如 m_freeCnt = 34? 就是當(dāng)前頁(yè)面的剩余空間，這個(gè)和我們剛才的計(jì)算公式是保持一致的，這 34byte? 就是頁(yè)面末位默認(rèn)的 0x21 填充符。
三：總結(jié)
其實(shí)從上面的分析中可以得出，數(shù)據(jù)頁(yè)還是有 34byte 的保留空間的，可能是出于某些原因不想再塞了，當(dāng)然也可以用 WinDbg 觀察下源碼邏輯，可以下一個(gè) C++ 異常斷點(diǎn)。
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
...
從線程?？梢钥吹剑壿嬍窃?nbsp;SECreateRowset()? 方法中拋出了 RaiseHoBtRowsizeError() 異常，應(yīng)該是一個(gè)常量 cmp 比較，留給大家研究吧。
