MySQL InnoDB 磁盤架構：如何管理和存儲各數據？系統表、獨立表、通用表、撤銷表、臨時表空間是什么？表和索引如何管理?

作者：碼哥字節@李健青 2025-05-26 08:37:17

在聚集索引中，數據頁內除了按照主鍵大小進行記錄存放以外，在??File header??中，有兩個字段：??fil_page_prev?? 和??fil_page_next??, 分別記錄了上一頁/下一頁的偏移量（offset），用以實現數據頁在 B+ Tree 葉子位置的雙向鏈表結構。

MySQL innoDB 引擎架構可以分為兩大塊，分別是內存架構（In-Memory Structure）和磁盤架構（On-Disk Structure）。

圖 1 圖 1

書接上回《MySQL InnoDB 架構 Buffer Pool、Change Buffer、自適應哈希索引、Log Buffer》，我們掌握了 InnoDB 引擎的內存架構。

數據最終要持久化到磁盤，其磁盤架構設計融合了復雜的存儲結構和精巧的機制，本文將深入剖析其核心模塊的設計原理，并通過圖片輔助理解。

MySQL 到底是怎么管理和存儲各種各樣的數據呢？比如創建一張表、索引、表中的每一行數據、查詢過程中臨時存儲的數據都存在哪里，又如何管理？

這一切都歸功于 MySQL 的 Tablespaces （表空間）的設計，內容較多，本篇就關于以下類型 Tablespaces （表空間）作用和實現原理展開：

系統表空間（System Tablespace）
獨立表空間（File-Per-Table Tablespaces）
通用表空間（General Tablespaces）
撤銷表空間（Undo Tablespaces）
臨時表空間（Temporary Tablespaces）
Tables（表）
Indexes（索引）

Tablespaces （表空間）

表空間可以看做是 InnoDB 存儲引擎邏輯結構的最高層，所有的數據都存放在表空間中，稱之為表空間（tablespace）。

從物理文件的分類來看：

日志文件（Undo Log、Redo Log）。
系統表空間（System Tablespace）文件 ibdata1。
Undo tablespace 。
獨立表空間（File-Per-Table Tablespaces）
通用表空間（General Tablespaces）
臨時表空間文件（Temporary Tablespaces）

所以表空間根據不同的場景也分了多種類型，我分別介紹下……

系統表空間（System Tablespace）

默認配置下會有一個初始大小為 10MB，名為 ibdata1 的文件。該文件就是默認的表空間文件（tablespace file）。

系統表空間是 Change Buffer 的存儲區域。

如果表是在系統表空間而非獨立表空間或通用表空間中創建的，它也可能包含表和索引數據。

增加系統表空間大小的最簡單方法是將其配置為自動擴展。

為此，在 innodb_data_file_path 設置中為最后一個數據文件指定 autoextend 屬性，并重啟服務器。

innodb_data_file_path=ibdata1:10M:autoextend

為避免系統表空間過大，可考慮使用獨立表空間或通用表空間存儲數據。

獨立表空間是默認的表空間類型，在創建 InnoDB 表時會隱式使用。

獨立表空間（File-Per-Table Tablespaces）

獨立表空間，顧名思義，就是用戶創建的表空間，如果開啟獨立表空間參數，那么一個表空間會對應磁盤上的一個物理文件，每張表對應一個文件，支持事務獨立管理。

其實表空間文件內部還是組織為更復雜的邏輯結構，自頂向下可分為 segment（段）、extent（區）和 page（頁）。

page 則是表空間數據存儲的基本單位，innodb 將表文件（xxx.ibd）按 page 切分，依類型不同，page 內容也有所區別，最為常見的是存儲數據庫表的行記錄。

表空間下一級稱為 segment。segment 與數據庫中的索引相映射。

Innodb 引擎內，每個索引對應兩個 segment：管理葉子節點的 segment 和管理非葉子節點 segment。

創建索引中很關鍵的步驟便是分配 segment，Innodb 內部使用 INODE 來描述 segment。

segment 的下一級是 extent，extent 代表一組連續的 page，默認為 64 個 page，大小 1MB。

InnoDB 存儲引擎的邏輯存儲結構大致如圖 2 所示。

圖 2 圖 2

默認情況下 InnoDB 存儲引擎有一個共享表空間 ibdata1，即所有數據都存放在這個表空間內。

如果用戶啟用了參數innodb_file_per_table，則每張表內的數據可以單獨放到一個表空間內。

如果啟用了innodb_file_per_table的參數，需要注意的是每張表的表空間內存放的只是數據、索引和插入緩沖 Bitmap 頁.

其他類的數據，如回滾（undo）信息，插入緩沖索引頁、系統事務信息，二次寫緩沖（Double write buffer）等還是存放在原來的系統表空間內。

通用表空間（General Tablespaces）

通用表空間是一種共享的 InnoDB 表空間，通過 CREATE TABLESPACE 語法創建。

通用表空間提供以下功能：

類似于系統表空間，通用表空間是一種共享表空間，能夠存儲多張表的數據。
通用表空間在內存占用上可能優于獨立表空間。服務器會在表空間生命周期內將表空間元數據保留在內存中。相較于相同數量的表分散在多個獨立表空間中，更少的通用表空間內存儲多張表能減少表空間元數據的內存消耗。

通用表空間通過 CREATE TABLESPACE 語法創建。

CREATE TABLESPACE tablespace_name
    [ADD DATAFILE 'file_name']
    [FILE_BLOCK_SIZE = value]
        [ENGINE [=] engine_name]

通用表空間有什么不足？

通用表空間限制有以下限制：

現有的表空間無法更改為通用表空間。
不支持創建臨時通用表空間。
通用表空間不支持臨時表。
不支持將表分區放置在通用表空間中。
在復制環境中，如果源和副本位于同一主機上，則不支持使用 ADD DATAFILE 子句，因為這會導致源和副本在同一位置創建同名的表空間，而這是不被支持的。

撤銷表空間（Undo Tablespaces）

MySQL InnoDB 引擎的 Undo Tablespaces（撤銷表空間）是磁盤架構設計中用于管理事務回滾日志（Undo Log）的核心組件。

唐二婷：InnoDB 引擎的 Undo Tablespaces（撤銷表空間）有啥用？

Undo 日志（Undo Log）主要用于事務異常時的數據回滾，在磁盤上 undo 日志保存在 Undo Tablespaces 中。

事務回滾與 MVCC 支持Undo 表空間存儲的 Undo Log 記錄了事務對數據的修改前鏡像，用于：

事務回滾時恢復數據原狀；

實現多版本并發控制（MVCC），支持非鎖定一致性讀。

分離系統表空間負載在 MySQL 5.7 之前，Undo Log 默認存儲在系統表空間（ibdata1）中。
隨著事務頻繁操作，ibdata1 文件會無限增長且無法自動回收空間。
5.7 及更高版本引入獨立 Undo 表空間，通過物理隔離減輕系統表空間壓力，提升性能。

MySQL 8.0 默認創建 2 個 Undo 表空間文件（undo_001 和 undo_002），每個初始大小為 16MB，通過參數 innodb_undo_tablespaces 可調整數量（范圍 2-127），每個文件初始 16MB，支持自動擴展和截斷回收。

圖片

唐二婷：“Undo 表空間的邏輯層級管理是咋樣的？”

回滾段（Rollback Segments）：每個 Undo 表空間包含 128 個回滾段（由 innodb_rollback_segments 控制），每個回滾段管理 1024 個 Undo 段（Undo Segments）。

Undo 頁與日志記錄：Undo 段由多個 16KB 的頁組成，按事務類型分為 Insert Undo 段（僅用于回滾）和 Update Undo 段（用于 MVCC），前者事務提交后立即釋放，后者需等待無活躍讀視圖時清除。

通過多 Undo 表空間與回滾段的分區設計，理論上支持高達數萬級并發事務（例如：128 表空間 × 128 回滾段 × 1024 Undo 段）。

如下圖所示。

圖片

關鍵說明：

每個 Undo 表空間包含 128 個回滾段
每個回滾段管理 1024 個 Undo 段（按事務類型分類）
Undo 段由 16KB 頁 組成，存儲具體日志記錄

唐二婷：說說 Undo Log 與 MVCC 的協作機制

Undo Log 與 MVCC 的協作機制如下圖所示：

圖片

運作原理：

事務修改前將舊數據寫入 Undo Log
讀事務通過 Read View 判斷可見性
多版本數據通過 Undo Log 鏈回溯訪問

唐二婷：“系統表空間與 Undo 表空間存儲有啥區別？”

圖片

特性	Undo 表空間	系統表空間（歷史方案）
存儲內容	僅 Undo Log	數據字典、雙寫緩沖、Undo Log 等混合內容
空間管理	支持自動截斷，避免文件膨脹	無法自動回收，需手動調整或重建
性能影響	減少 I/O 競爭，提升并發處理能力	高頻事務易導致文件過大，性能下降
版本支持	MySQL 5.7+ 默認方案	MySQL 5.6 及更早版本

臨時表空間（Temporary Tablespaces）

InnoDB 臨時表空間分為 會話臨時表空間 和 全局臨時表空間，分別承擔不同角色：

會話臨時表空間（Session Temporary Tablespaces）

用途：存儲用戶顯式創建的臨時表（CREATE TEMPORARY TABLE）以及優化器生成的內部臨時表（如排序、分組操作）。
生命周期：會話斷開時自動截斷并釋放回池，文件擴展名為 .ibt，默認位于 #innodb_temp 目錄。
分配機制：首次需要創建磁盤臨時表時，從預分配的池中分配（默認池包含 10 個表空間文件），每個會話最多分配 2 個表空間（用戶臨時表與優化器內部臨時表各一）。

全局臨時表空間（Global Temporary Tablespace）：

用途：存儲用戶臨時表的回滾段（Rollback Segments），支持事務回滾操作。
文件配置：默認文件名為 ibtmp1，初始大小 12MB，支持自動擴展，由參數 innodb_temp_data_file_path 控制路徑與屬性。
回收機制：服務器重啟時自動刪除并重建，意外崩潰時需手動清理。

Temporary Tablespaces 物理結構

圖片

圖示說明：

全局臨時表空間：ibtmp1 存儲用戶臨時表的回滾段
會話臨時表空間：#innodb_temp 目錄下預分配 10 個 .ibt 文件池（默認配置）
每個會話最多激活 2 個臨時表空間（用戶臨時表 + 優化器內部臨時表）。

會話級臨時表空間生命周期

圖片

關鍵點：

首次需要磁盤臨時表時從池中分配
會話斷開連接后立即歸還空間
文件物理保留但內容截斷（類似內存池機制）

臨時表空間使用查詢流程

前面說過臨時表空間可存儲用戶顯式創建的臨時表（CREATE TEMPORARY TABLE）以及優化器生成的內部臨時表（如排序、分組操作）。

那它的查詢過程是怎樣的呢？

圖片

Tables（表）

唐二婷：“在 MySQL 如何創建一張表？”

InnoDB 表通過 CREATE TABLE 語句創建；例如：

CREATE TABLE t1 (a INT, b CHAR (20), PRIMARY KEY (a)) ENGINE=InnoDB;

默認情況下， InnoDB 表創建于每表獨立的表空間中。若要在 InnoDB 系統表空間中創建 InnoDB 表，需在創建表前禁用 innodb_file_per_table 變量。

比如，在數據庫 test 中創建一個表 show_index ，在 mysql 的 dataDirectory 目錄下就回出現一個名為 show_index.ibd 的數據文件。

在單個表的數據文件中，數據就是以多個頁的形式進行排列。MySQL 默認配置下，每 16K，即為一個頁。

InnoDB 表以 B+樹 組織數據，每個表對應一個 聚簇索引（Clustered Index），數據行的物理存儲順序與主鍵順序一致。

若未顯式定義主鍵，InnoDB 會隱式生成一個 6 字節的 Row ID 作為主鍵。

Row Formats 行格式

唐二婷：表中的每一行數據是怎么存儲的？

表的 InnoDB 行格式決定了其行在磁盤上的物理存儲方式。

InnoDB 支持四種行格式，每種格式具有不同的存儲特性。

支持的行格式包括 REDUNDANT 、 COMPACT 、 DYNAMIC 和 COMPRESSED 。其中， DYNAMIC 行格式為默認格式。

唐二婷：它們有啥區別？

REDUNDANT 和 COMPACT 行格式支持的最大索引鍵前綴長度為 767 字節，而 DYNAMIC 和 COMPRESSED 行格式則支持 3072 字節的索引鍵前綴長度。

在復制環境中，若源服務器上的 innodb_default_row_format 變量設置為 DYNAMIC ，而副本上設置為 COMPACT ，則以下未明確指定行格式的 DDL 語句在源服務器上執行成功，但在副本上會失敗。

Primary Keys 主鍵

建議為創建的每個表定義一個主鍵。在選擇主鍵列時，應選擇具有以下特征的列：

重要的查詢語句使用的列。
列不能為空。
從不包含重復值的列。
一旦插入后極少甚至從不更改值的列。

例如，在包含人員信息的表中，你不會將主鍵設在 (firstname, lastname) 上，因為可能有多個人員擁有相同的姓名，姓名列可能留空，且有時人們會更改姓名。

面對如此多的限制條件，通常沒有明顯的一組列適合作為主鍵，因此你會創建一個帶有數字 ID 的新列，作為主鍵。

最好的方式就是使用趨勢遞增的數字作為主鍵。

你也可以在 InnoDB 表中使用 AUTO_INCREMENT 的列來定義主鍵自動生成。

AUTO_INCREMENT 實現原理是什么？會鎖全表碼？

自增鎖模式通過 innodb_autoinc_lock_mode 變量在啟動時配置。

自增主鍵鎖

“傳統”鎖模式

innodb_autoinc_lock_mode = 0 （“傳統”鎖模式），所有“INSERT 類”語句在向具有 AUTO_INCREMENT 列的表中插入時都會獲得一個特殊的表級 AUTO-INC 鎖。

此鎖通常保持到語句的末尾（而不是事務的末尾），以確保在給定的 INSERT 語句序列中自動增量值按可預測和可重復的順序分配，并確保任何給定語句分配的自動增量值是連續的。

“連續”鎖模式

innodb_autoinc_lock_mode = 1 （“連續”鎖模式），“批量插入”使用特殊的 AUTO-INC 表級鎖，并保持到語句結束。這適用于所有 INSERT ... SELECT 、 REPLACE ... SELECT 和 LOAD DATA 語句。

這種鎖模式確保，在存在 INSERT 語句且行數未知（并且自增值在語句執行過程中分配）的情況下，任何“ INSERT -類似”語句分配的所有自增值都是連續的，并且操作對基于語句的復制是安全的。

innodb_autoinc_lock_mode = 2 （“交錯”鎖模式）

在這種鎖模式中，沒有“ INSERT -like”語句使用表級 AUTO-INC 鎖，并且多個語句可以同時執行。

這是最快且最可擴展的鎖模式，但在使用基于語句的復制或從二進制日志重放 SQL 語句的恢復場景時是不安全的。

在此鎖定模式下，自動增量值在整個并發執行的“ INSERT -like”語句中保證是唯一的且單調遞增。

然而，由于多個語句可以同時生成數字（即，數字的分配在語句之間交錯進行），任何給定語句插入的行生成的值可能不是連續的。

Indexes（索引）

InnoDB 的索引分為 聚簇索引 和 二級索引（Secondary Index），均采用 B+樹結構：

聚簇索引：也稱 Clustered Index。是指關系表記錄的物理順序與索引的邏輯順序相同。由于一張表只能按照一種物理順序存放，一張表最多也只能存在一個聚集索引。葉子節點直接存儲行數據。
二級索引：也叫 Secondary Index。指的是非葉子節點按照索引的鍵值順序存放，葉子節點存放索引鍵值以及對應的主鍵鍵值。MySQL 里除了 INNODB 表主鍵外，其他的都是二級索引。葉子節點存儲主鍵值，需通過主鍵回表查詢數據。

下圖是一個聚集索引的 B+ Tree 圖。

圖片

1 個 B+ Tree Node，占據一個頁。

在索引頁，頁的主要記錄部分(User Records)存放的Record = record header + index key + page pointer。
在數據頁，則是按表創建時的row_format類型存放完整數據行記錄。 row_format 類型分別有：Compact、Redundant、Compressed和Dynamic。

因此，在聚集索引中，非葉子節點都為索引頁，葉子節點為數據頁；

在輔助索引中，非葉子節點和葉子節點都為索引頁。不同的是，葉子節點里記錄的是聚集索引中的主鍵 ID 值。

INNODB 表的二級索引，如下圖所示，圖片來自「一樹一溪」：

圖片

注意，在索引頁的 Record 中的page pointer，指向的是頁，而非具體的記錄行。

并且 Record 的index key，為指向的 page records 的起始鍵值。

如果主鍵較長，二級索引會占用更多空間，因此擁有較短的主鍵是有利的。

在表空間文件的一個頁的結構上，內容布局為：

圖片

在聚集索引中，數據頁內除了按照主鍵大小進行記錄存放以外，在File header中，有兩個字段：fil_page_prev 和fil_page_next, 分別記錄了上一頁/下一頁的偏移量（offset），用以實現數據頁在 B+ Tree 葉子位置的雙向鏈表結構。

數據如何被查找檢索呢？

通過 B+ Tree 結構，可以明顯看到，通過 B+ Tree 查找，可以定位到索引最后指向的數據頁，并不能找到具體的記錄本身。

這時，數據庫會將該頁加載到內存中，然后通過Page Directory進行二分查找。

責任編輯：武曉燕來源：碼哥跳動