你以為你寫了一條 SQL，其實你是在和數據庫的一整套存儲機制打交道。

一、引言：懂記錄結構，真的很重要！

開篇三連擊：

• 當你敲下INSERT時，數據是在磁盤「蓋房子」還是「搭積木」？
• 行格式里藏著哪些「加密代碼」？
• 一條“莫名其妙”的慢查詢，根源可能是行格式選錯？

這些問題的答案，就藏在 InnoDB 的記錄結構里。

我們在寫 SQL 的時候，經常只關注“寫對了沒”、“跑起來沒報錯”。但真正理解 MySQL 的底層行為，往往要從一句簡單的 INSERT 開始。

二、從一條INSERT語句開始說起

當我們執行INSERT INTO users (name, age,address) VALUES ('張三', 25,'北京.海淀');這條語句時，數據并不會直接 “一股腦” 地塞進磁盤。InnoDB 會按照特定的規則，將數據 “搭建” 成特定的結構，然后再存儲到磁盤上。

為了更好地理解這個過程，我們先來對比一下行數據以及行結構。

假設我們有一張users表，包含id、name、age、address四個字段。

CREATE TABLEusers (
    idINTUNSIGNEDNOTNULL AUTO_INCREMENT COMMENT'主鍵ID',
    nameVARCHAR(100) NOTNULLCOMMENT'用戶姓名',
    age INTUNSIGNEDCOMMENT'年齡',
    address VARCHAR(255) COMMENT'地址',
    PRIMARY KEY (id)
) ENGINE=InnoDBDEFAULTCHARSET=utf8mb4 COMMENT='用戶信息表';

當我們插入一條數據(1, '張三', 25,'北京.海淀')時，從表面上看，我們看到的行數據是這樣的：

然而在 InnoDB 中，一條數據并非簡單存儲，而是拆分成多個部分：記錄頭信息保存元數據，變長字段列表記錄變長字段及長度，NULL 值列表標記哪些字段為 NULL。

InnoDB目前支持四種行格式：

• COMPACT（最常用）
• REDUNDANT（MySQL 5.0之前）
• DYNAMIC（MySQL 5.7默認）
• COMPRESSED（壓縮格式）

COMPACT 行格式是最常用的“標準模板”，掌握它能幫助你理解 InnoDB 記錄結構的核心。

三、COMPACT 行格式詳細介紹：數據存儲的 “標準模板”

廢話不多說，直接看圖：

1. 記錄頭信息：數據的 “身份證”

記錄頭信息僅占5字節，卻包含記錄類型、刪除標記、B+樹位置等關鍵信息，是記錄的重要標識。

當我們執行DELETE語句刪除一條記錄時，InnoDB 并不會立即從磁盤上刪除這條記錄，而是在記錄頭信息中設置刪除標記，后續再通過專門的機制進行清理。

2. 變長字段列表：應對 “變化多端” 的數據

在實際應用中，很多字段的數據長度是不固定的，比如VARCHAR、TEXT、BLOB等類型的字段。變長字段列表就是為了應對這些 “變化多端” 的數據而設計的。它會記錄哪些字段是變長的，以及它們的長度。

變長字段列表采用倒排的方式存儲，也就是說，它從右往左存儲每個變長字段的長度。

(1) 變長字段列表如何存儲實際數據？

當執行插入語句INSERT INTO users VALUES(1, '張三', 25, '北京.海淀');時，我們來分析一下變長字段列表的存儲方式。

① 字段分析

• id：INT 類型，固定長度 4 字節，不屬于變長字段
• name：VARCHAR (100)，實際存儲 ' 張三 '，UTF-8 編碼下每個漢字占 3 字節，共 6 字節
• age：INT 類型，固定長度 4 字節，不屬于變長字段
• address：VARCHAR (255)，實際存儲 ' 北京.海淀 '，共包含 5 個字符（2 個漢字、1 個點、2 個漢字），每個漢字 3 字節，點 1 字節，共 13 字節

② 變長字段列表的倒排存儲

上面的例子中，有兩個變長字段：name和address。它們的長度分別是 6 字節和 13 字節。根據倒排存儲規則，變長字段列表會按照從右到左的順序記錄這些長度。

• 表定義順序是：name, address
• 倒排后，存的時候順序是：address, name

因此，變長字段列表的內容為：[13,6]。

這些值并不是直接以十進制存入，而是編碼成 1~2 字節的二進制形式（依字段長度大小決定）。

3. NULL 值列表：節省空間的 “小能手”

在 InnoDB 中，NULL 值列表是一種節省空間的巧妙設計。它不存儲 NULL 的實際值，而是用每個字段對應的一位二進制位來標記：

• 1 表示該字段為 NULL；
• 0 表示不為 NULL。

在計算 InnoDB 記錄結構中的 NULL 值列表時，只有那些“允許為 NULL”的字段才會被納入統計。

以 users 表為例：

• id 是主鍵，不能為 NULL；
• name 被 NOT NULL 明確聲明，也不能為 NULL；
• age 和 address 沒有限定 NOT NULL，默認是可以為 NULL 的。

所以，NULL 值列表中只包含 age 和 address 這兩個字段的狀態位。

NULL 值列表的位順序，是按照表結構中允許 NULL 字段的出現順序排列的，且僅包含這些字段。

四、行溢出：當數據太大時會發生什么？

1. 為什么會出現行溢出？

InnoDB 的數據存儲以 “頁” 為基本單位，每頁默認大小為 16KB。當我們插入的數據（如一篇幾萬字的文章、高清圖片的二進制數據）長度超過一頁能容納的空間時，InnoDB 就會遇到 “空間不夠用” 的難題。就像你想把 100 本書塞進只能裝 50 本書的箱子，自然裝不下。

2. 什么是行溢出？

為了解決上述問題，InnoDB 引入了行溢出機制：

• 當數據過長時，它會把超出數據頁容量的部分 “搬” 到額外的溢出頁中存儲；
• 并在原數據頁保留一個指向溢出頁的指針（通常是20字節）。

這就好比把裝不下的書先放在旁邊的臨時箱子，再在原本的箱子貼上標簽注明 “其余書在隔壁箱”。

行溢出雖解決大字段存儲，但帶來性能隱患，如查詢慢、空間管理復雜、碎片增多。優化可從多方面入手：拆大字段表、選適配數據類型與行格式，控制字段長度，同時避免在大字段建索引，以此提升數據庫性能。

五、結語：深入底層，才能掌控全局

數據庫的 “高性能密碼” 藏在底層結構里。從 INSERT 語句到磁盤存儲，COMPACT 行格式的字段管理、行溢出的優化邏輯，都是提升數據庫能力的關鍵。懂記錄結構，才能在面試中從容應答，在優化時直擊痛點。

記住：深挖底層原理，才能讓技術成長 “知其所以然”。歡迎留言交流，一起解鎖更多數據庫奧秘！