說在前面——本篇也是我讀書總結筆記，因為是講底層原理，我個人認為本文難度是相當高的，可能需要一定的基礎，

我將文中的圖片包含的計算原理全都演算了一遍，因為書本沒有程序詳細計算，歡迎大家閱讀和仔細推敲，

如果是大忙人，也可以跳過計算，看懂程序和大致原理即可，

1.記錄頭資訊有什么用？

??記錄頭資訊里面有很多屬性，最容易理解的就是next_record指標，單鏈表都會有next指標，這樣才會找得到下一個結點，這對于頁中的每條記錄也是一樣，上一條記錄需要知道下一條記錄在哪里，

??上一篇說到了innodb行格式，重點講了一下dynamic行格式，知道一條記錄實際存盤如下圖，沒辦法，說到底層原理如果不看上一篇文章是不可能完全理解的，耶穌來了也沒法一篇說明白，見這里MySQL的varchar水真的太深了——InnoDB記錄存盤結構，必須記住下圖的上面行格式部分，每條記錄不僅是記錄的真實資料，還有記錄的額外資訊，

如果你目前只是為了開發學習本部分知識，那么可以直接跳到本篇第4、5節，傳送–>

??如果欄位沒有被NOT NULL限定，那么就允許為NULL，該列就會有NULL值串列，

??關于記錄頭資訊，下面這個表先列出來，往后面看的時候不理解時可以回傳查看這個表，方便理解，

從表中所說可以看到，記錄頭資訊一共是40bit就是5個位元組

2.記錄在頁中的存盤結構

??頁是innodb管理存盤空間的基本單位，一個頁的大小默認是16KB，插入的記錄會按照指定的行格式(默認dynamic)存盤到User Records部分，但是在一開始生成頁的時候，其實并沒有User Records這個部分，每當我們插入一條記錄，都會從Free Space部分(也就是尚未使用的存盤空間) 申請一個記錄大小的空間，并將這個部分劃分到User Records部分，當Free Space部分的空間全部被User Records部分替代掉之后，也就意味著這個頁使用完了，如果還有新的記錄插入的話，就需要去申請新的頁了，

有人會疑問了，圖中這個Infimum+Supremum是什么？

?? Infimum記錄 的下一條記錄就是本頁中主鍵值最小的用戶記錄，而本頁中主鍵值最大的用戶記錄的下一條記錄就是 Supremum記錄，但是這兩條記錄不在User Records部分，是單獨占用的空間，可結合上一張圖理解，都是由5個位元組的記錄頭和8個位元組的一個固定單詞組成，如下所示

3.記錄頭資訊的底層原理和計算（show time，難度搞起來）

首先，建個表record_test

CREATE TABLE record_test(
 c1 INT,
 c2 INT,
 c3 VARCHAR(10000),
  PRIMARY KEY (c1)
) CHARSET=utf8mb4;

執行插入陳述句

INSERT INTO record_test VALUES(1, 100, 'aa你好'), (2, 200, 'bb哈哈'), (3, 300, 'cc來了'), (4, 400, 'dd在哪');

最終表資料如下

這4條記錄的存盤結構示意圖如下

注意：
1.圖中畫記錄的時候只選取了記錄頭的一部分，省略了變長串列和NULL值串列，但是實際計算的時候要帶上，
2.這里把隱藏列省略了，歸并到 “其他資訊” 里面了

??看到這里，你一定和我有著相同的疑問，為什么next_record顯示36，它表示本條記錄真實資料部分到下一條記錄真實資料的距離，這個怎么計算的呢？

??現在我來和你說說底層那些不為人知的東西，要知道，記錄的真實資料除了所有的資料列之外，MySQL還會為每條記錄默認添加一些列（也稱為隱藏列），隱藏列也包含在記錄的真實資料部分，如下

??InnoDB表對主鍵的生成策略：優先使用用戶自定義主鍵作為主鍵，如果用戶沒有定義主鍵，則選取一個Unique鍵作為主鍵（必須NOT NULL不允許存NULL值），如果表中連Unique鍵都沒有定義的話，則InnoDB會為表默認添加一個名為DB_ROW_ID的隱藏列作為主鍵，

??從上表中可以看出：InnoDB存盤引擎會為每條記錄都添加 DB_TRX_ID和 DB_ROLL_PTR這兩個列，但是 DB_ROW_ID是可選的（在沒有自定義主鍵以及不允許存NULL值的Unique鍵的情況下才會添加該列），這些隱藏列的值不用我們操心，InnoDB存盤引擎會自己幫我們生成的，

所以剛剛next_record為36位元組的計算方法就是
6+7（隱藏列2個，因為有自定義主鍵）=13位元組
4(int長度)+4(int長度)+8(變長varchar實際位元組數)=16位元組
下一列記錄的額外資訊（變長串列+NULL值串列+記錄頭）
1+1+5=7位元組
總共13+16+7=36

注意，圖中畫記錄的時候只選取了記錄頭的一部分，計算的時候直接記錄頭按5位元組計算，加上變長串列長度和NULL值串列長度即可，

如果變長串列NULL值串列不知道怎么計算長度，見上一篇MySQL的varchar水真的太深了——InnoDB記錄存盤結構，不看上篇不可能理解的，

而且你可能會疑問為什么第4條記錄的下一條卻要-123位元組？

??前面說過，最大記錄的下一條記錄是Supremum記錄，而Infimum記錄的heap_no為0，而Supremum記錄的heap_no為1，存放位置是在所有記錄之前，最小記錄的heap_no是從2開始的，前面給大家看過記錄在頁中的存盤結構，知道Infimum和Supremum記錄在User Records之前，

??所以最大記錄的下一條就是要找到Supremum記錄，那么就要往回走3條記錄和第一條記錄的最小記錄變長串列+NULL值串列+頭資訊（共7位元組），然后加上Supremum真實資料部分的固定8個位元組，

36*3+7+8=123位元組

??所以為第4條記錄的next_record為-123，代表指標往前走123位元組就是下一條記錄的真實資料部分的地址，


如果你還細致的觀察到Infimum記錄的next_record是28，我覺得你挺適合做研究，

??在存盤結構上，Infimum記錄后面是Supremum記錄，接著才是第一條資料記錄，
??邏輯上，Infimum下一條記錄是第一條資料記錄，所以計算方法是
8(Infimum固定位元組) + 5(Supremum記錄頭) + 8(Supremum固定位元組) + 7(第一條資料記錄的變長欄位串列+NULL值串列+記錄頭) = 28位元組，

??為了更形象的表現next_record的作用，我們用箭頭來替代next_record的值，注意箭頭指向的位置，都是指向真實資料開始的地址，

你可能會疑問，為啥要next_record指向記錄頭資訊和真實資料之間的位置呢？指向整條記錄的開頭位置不好嗎？

??因為這個位置剛剛好，向左讀取就是記錄頭資訊，向右讀取就是真實資料，我們前邊還說過變長欄位長度串列、NULL值串列中的資訊都是逆序存放，這樣可以使記錄中位置靠前的欄位和它們對應的欄位長度資訊在記憶體中的距離更近，可能會提高高速快取的命中率，

4.當記錄被洗掉，頁中記錄存盤結構如何變化？

當然最大的疑問就是被洗掉的記錄還在頁中么？
??是的，你以為記錄洗掉了，可它還在真實的磁盤上（占用空間依然存在），這些被洗掉的記錄之所以不從磁盤上移除，是因為移除它們之后，還需要再磁盤中重新排序其他記錄，這會帶來一定的性能損耗，所以只是打一個洗掉標記就可以避免這個問題，首先deleted_mask設定為1，然后被洗掉掉的記錄加入到垃圾鏈表，記錄在這個鏈表中占用的空間稱為可重用空間，之后如果有新記錄插入到表中的話，它們就可能覆寫掉被洗掉的這些記錄占用的空間，

來演示一下

delete from record_test where c1 = 2;

發現第二條記錄被刪了

在記憶體中是怎么樣的呢？

洗掉第2條記錄變化如下

• 第2條記錄并沒有從存盤空間中移除，而是把該條記錄的delete_mask值設定為1，
• 第2條記錄的next_record值變為了0，意味著該記錄沒有下一條記錄了，
• 第1條記錄的next_record指向了第3條記錄，
• 最大記錄的n_owned值從5變成了4，因為除了自身Supremum記錄外，還有3條資料記錄（注：Infimum的n_owned為1是因為包含自身算一條記錄）

??無論怎么對頁中的資料進行增刪改操作，InnoDB始侄訓維護記錄的一個單向鏈表，鏈表中的各個節點是按照主鍵值從小到大的順序鏈接起來的，

5.當洗掉的記錄再次被插入，頁中記錄存盤結構如何變化？

INSERT INTO record_test VALUES(2, 200, 'bb哈哈');

可以看到，剛剛洗掉的第二條資料又回來了

記憶體結構變化如下

??InnoDB并沒有因為新記錄的插入而為它申請新的存盤空間，而是直接復用了原來被洗掉記錄的存盤空間，

??當資料頁中存在多條被洗掉掉的記錄時，這些記錄的next_record屬性將會把這些被洗掉掉的記錄組成一個垃圾鏈表，以備之后重用這部分存盤空間，


本篇總結：
??本篇主要講了Infimum+Supremum部分，分別是頁中最小記錄的前一個和最大記錄的后一個記錄，User Records部分使我們插入的真實資料部分，Free Space是頁總尚未使用的部分，然后講解了圖中next_record指標地址的計算，
??我們知道，頁中的記錄是單鏈表，頁與頁之間是雙向鏈表，其實每個資料頁的File Header部分有上一頁和下一頁的編號，所以所有資料頁會組成一個雙向鏈表，