您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

深度剖析 MySQL InnoDB 索引：從 B+樹到頁面儲存全景圖

編輯：MySQL 綜合教學

深度剖析 MySQL InnoDB 索引：從 B+樹到頁面儲存全景圖

InnoDB 是 MySQL 5.5.5 版本後的預設儲存引擎，其索引實作基於 B+樹。本文從樹形結構演進、索引組織方式、頁面儲存細節三個維度，系統梳理 InnoDB 索引核心原理。

一、樹形結構演進：為什麼是 B+樹？

樹類型	關鍵特性	適用場景
二元搜尋樹	每節點兩個子節點，資料量增大導致樹高快速增長	教學示意，不適合大量資料
B 樹	平衡多路搜尋樹，資料同時存在葉子與非葉子節點，須中序遍歷	早期資料庫索引
B+樹	非葉子節點僅存鍵值，葉子節點存全量資料並雙向鏈表連接，支援範圍查詢與全表掃描	現代關聯式資料庫主流選擇
B*樹	非葉子節點加入橫向指標，分裂策略更複雜（兄弟節點借位/三分裂）	理論研究，工程落地少

B+樹分裂機制

節點滿時分配新節點，原節點一半資料移至新節點
父節點新增指標，不影響兄弟節點，故無需兄弟指標
分裂過程為遞歸，可能導致樹高增加

為什麼資料庫選擇 B+樹？

核心原因在於兩層儲存架構：記憶體（快、小）與機械硬碟（慢、大）。B+樹扁平特性（高度通常 3-4 層）配合頁面預讀，將磁碟 I/O 次數控制在極低水平。非葉子節點常駐記憶體，葉子節點按需讀取，單次查詢僅需 1-3 次磁碟 I/O。

二、儲存引擎與索引組織：聚簇 vs 非聚簇

特性	InnoDB（聚簇索引）	MyISAM（非聚簇索引）
主鍵 B+樹葉子節點	存放完整行資料	存放資料指標（檔案偏移量）
輔助索引 B+樹葉子節點	存放輔助鍵 + 主鍵值	存放輔助鍵 + 資料指標
輔助索引查詢流程	兩次 B+樹查找（輔助索引→主鍵→聚簇索引）	一次 B+樹查找（輔助索引→資料指標）
行遷移/頁分裂維護成本	低（主鍵值不變，輔助索引無需更新）	高（指標變更需更新所有輔助索引）

聚簇索引優勢：主鍵查詢極快；輔助索引用主鍵作「邏輯指標」避免物理位置變更帶來的維護開銷。

三、頁面結構：InnoDB 儲存最小單元

頁面大小：16KB（可透過 UNIV_PAGE_SIZE 編譯調整）
頁面類型：資料頁、Undo 頁、系統頁、事務資料頁等
頁面編號：32 位整數，支援 64TB 最大儲存

頁面內部佈局

+------------------+
| File Header (38B)  ← 前/後頁指標、頁面類型、頁號
+------------------+
| Page Header (56B)  ← 頁面狀態、記錄數、堆頂指標等
+------------------+
| Infimum Record     ← 虛擬最小記錄（單向鏈表頭）
+------------------+
| User Records       ← 實際資料記錄（單向鏈表串聯）
+------------------+
| Supremum Record    ← 虛擬最大記錄（單向鏈表尾）
+------------------+
| Free Space         ← 可用空間
+------------------+
| Page Directory     ← 槽位目錄（二分查找加速頁內定位）
+------------------+
| File Trailer (8B)  ← 校驗碼
+------------------+

四種記錄格式

記錄類型	關鍵欄位	說明
主索引非葉節點	Min Cluster Key、Child Page Number	導航用，僅存鍵值與子頁指標
主索引葉節點	Cluster Key、Non-Key Fields	完整行資料
輔助索引非葉節點	Min Secondary Key、Cluster Key、Child Page Number	輔助鍵+主鍵組合保證唯一性
輔助索引葉節點	Secondary Key、Cluster Key	回表查詢所需主鍵值