MySQL · 引擎特性 · InnoDB 文件系統之文件物理結構

綜述

從上層的角度來看，InnoDB層的文件，除了redo日志外，基本上具有相當統一的結構，都是固定block大小，普遍使用的btree結構來管理數據。只是針對不同的block的應用場景會分配不同的頁類型。通常默認情況下，每個block的大小為 UNIV_PAGE_SIZE，在不做任何配置時值為16kb，你還可以選擇在安裝實例時指定一個塊的block大小。對于壓縮表，可以在建表時指定block size，但在內存中表現的解壓頁依舊為統一的頁大小。

從物理文件的分類來看，有日志文件、主系統表空間文件ibdata、undo tablespace文件、臨時表空間文件、用戶表空間。

日志文件主要用于記錄redo log，InnoDB采用循環使用的方式，你可以通過參數指定創建文件的個數和每個文件的大小。默認情況下，日志是以512字節的block單位寫入。由于現代文件系統的block size通常設置到4k，InnoDB提供了一個選項，可以讓用戶將寫入的redo日志填充到4KB，以避免read-modify-write的現象；而Percona Server則提供了另外一個選項，支持直接將redo日志的block size修改成指定的值。

ibdata是InnoDB最重要的系統表空間文件，它記錄了InnoDB的核心信息，包括事務系統信息、元數據信息，記錄InnoDB change buffer的btree，防止數據損壞的double write buffer等等關鍵信息。我們稍后會展開描述。

undo獨立表空間是一個可選項，通常默認情況下，undo數據是存儲在ibdata中的，但你也可以通過配置選項 innodb_undo_tablespaces 來將undo 回滾段分配到不同的文件中，目前開啟undo tablespace 只能在install階段進行。在主流版本進入5.7時代后，我們建議開啟獨立undo表空間，只有這樣才能利用到5.7引入的新特效：online undo truncate。

MySQL 5.7 新開辟了一個臨時表空間，默認的磁盤文件命名為ibtmp1，所有非壓縮的臨時表都存儲在該表空間中。由于臨時表的本身屬性，該文件在重啟時會重新創建。對于云服務提供商而言，通過ibtmp文件，可以更好的控制臨時文件產生的磁盤存儲。

用戶表空間，顧名思義，就是用于自己創建的表空間，通常分為兩類，一類是一個表空間一個文件，另外一種則是5.7版本引入的所謂General Tablespace，在滿足一定約束條件下，可以將多個表創建到同一個文件中。除此之外，InnoDB還定義了一些特殊用途的ibd文件，例如全文索引相關的表文件。而針對空間數據類型，也構建了不同的數據索引格式R-tree。

在關鍵的地方本文注明了代碼函數，建議讀者邊參考代碼邊閱讀本文，本文的代碼部分基于MySQL 5.7.11版本，不同的版本函數名或邏輯可能會有所不同。請讀者閱讀本文時盡量選擇該版本的代碼。

文件管理頁

InnoDB 的每個數據文件都歸屬于一個表空間，不同的表空間使用一個唯一標識的space id來標記。例如ibdata1, ibdata2… 歸屬系統表空間，擁有相同的space id。用戶創建表產生的ibd文件，則認為是一個獨立的tablespace，只包含一個文件。

每個文件按照固定的 page size 進行區分，默認情況下，非壓縮表的page size為16Kb。而在文件內部又按照64個Page（總共1M）一個Extent的方式進行劃分并管理。對于不同的page size，對應的Extent大小也不同，對應為：

盡管支持更大的Page Size，但目前還不支持大頁場景下的數據壓縮，原因是這涉及到修改壓縮頁中slot的固定size（其實實現起來也不復雜）。在不做聲明的情況下，下文我們默認使用16KB的Page Size來闡述文件的物理結構。

為了管理整個Tablespace，除了索引頁外，數據文件中還包含了多種管理頁，如下圖所示，一個用戶表空間大約包含這些頁來管理文件，下面會一一進行介紹。

InnoDB 管理頁

文件鏈表

首先我們先介紹基于文件的一個基礎結構，即文件鏈表。為了管理Page，Extent這些數據塊，在文件中記錄了許多的節點以維持具有某些特征的鏈表，例如在在文件頭維護的inode page鏈表，空閑、用滿以及碎片化的Extent鏈表等等。

在InnoDB里鏈表頭稱為 FLST_BASE_NODE ，大小為 FLST_BASE_NODE_SIZE (16個字節)。BASE NODE維護了鏈表的頭指針和末尾指針，每個節點稱為 FLST_NODE ，大小為 FLST_NODE_SIZE （12個字節）。相關結構描述如下：

FLST_BASE_NODE :

FLST_NODE :

如上所述，文件鏈表中使用6個字節來作為節點指針，指針的內容包括：

該鏈表結構是InnoDB表空間內管理所有page的基礎結構，下圖先感受下，具體的內容可以繼續往下閱讀。

InnoDB 表空間page管理

文件鏈表管理的相關代碼參閱：include/fut0lst.ic, fut/fut0lst.cc

FSP_HDR PAGE

數據文件的第一個Page類型為 FIL_PAGE_TYPE_FSP_HDR ，在創建一個新的表空間時進行初始化( fsp_header_init )，該page同時用于跟蹤隨后的256個Extent(約256MB文件大小)的空間管理，所以每隔256MB就要創建一個類似的數據頁，類型為 FIL_PAGE_TYPE_XDES ，XDES Page除了文件頭部外，其他都和 FSP_HDR 頁具有相同的數據結構，可以稱之為Extent描述頁，每個Extent占用40個字節，一個XDES Page最多描述256個Extent。

FSP_HDR 頁的頭部使用 FSP_HEADER_SIZE 個字節來記錄文件的相關信息，具體的包括：

在文件頭使用FLAG（對應上述 FSP_SPACE_FLAGS ）描述了創建表時的如下關鍵信息：

除了上述描述信息外，其他部分的數據結構和XDES PAGE（ FIL_PAGE_TYPE_XDES ）都是相同的，使用連續數組的方式，每個XDES PAGE最多存儲256個XDES Entry，每個Entry占用40個字節，描述64個Page（即一個Extent）。格式如下：

XDES_STATE 表示該Extent的四種不同狀態：

通過 XDES_STATE 信息，我們只需要一個 FLIST_NODE 節點就可以維護每個Extent的信息，是處于全局表空間的鏈表上，還是某個btree segment的鏈表上。

IBUF BITMAP PAGE

第2個page類型為 FIL_PAGE_IBUF_BITMAP ，主要用于跟蹤隨后的每個page的change buffer信息，使用4個bit來描述每個page的change buffer信息。

由于bitmap page的空間有限，同樣每隔256個Extent Page之后，也會在XDES PAGE之后創建一個ibuf bitmap page。

INODE PAGE

數據文件的第3個page的類型為 FIL_PAGE_INODE ，用于管理數據文件中的segement，每個索引占用2個segment，分別用于管理葉子節點和非葉子節點。每個inode頁可以存儲 FSP_SEG_INODES_PER_PAGE （默認為85）個記錄。

每個Inode Entry的結構如下表所示：

文件維護

從上文我們可以看到，InnoDB通過Inode Entry來管理每個Segment占用的數據頁，每個segment可以看做一個文件頁維護單元。Inode Entry所在的inode page有可能存放滿，因此又通過頭Page維護了Inode Page鏈表。

在ibd的第一個Page中還維護了表空間內Extent的FREE、 FREE_FRAG 、 FULL_FRAG 三個Extent鏈表；而每個Inode Entry也維護了對應的FREE、 NOT_FULL 、FULL三個Extent鏈表。這些鏈表之間存在著轉換關系，以高效的利用數據文件空間。

當創建一個新的索引時，實際上構建一個新的btree( btr_create )，先為非葉子節點Segment分配一個inode entry，再創建root page，并將該segment的位置記錄到root page中，然后再分配leaf segment的Inode entry，并記錄到root page中。

當刪除某個索引后，該索引占用的空間需要能被重新利用起來。

當文件空間不足時，需要對文件進行擴展( fsp_try_extend_data_file )。文件的擴展遵循一定的規則：如果當前小于1個Extent，則擴展到1個Extent滿；當表空間小于32MB時，每次擴展一個Extent；大于32MB時，每次擴展4個Extent（ fsp_get_pages_to_extend_ibd ）。

在預留空間后，讀取文件頭Page并加鎖（ fsp_get_space_header ），然后開始為其分配Inode Entry( fsp_alloc_seg_inode )。首先需要找到一個合適的inode page。

我們知道Inode Page的空間有限，為了管理Inode Page，在文件頭存儲了兩個Inode Page鏈表，一個鏈接已經用滿的inode page，一個鏈接尚未用滿的inode page。如果當前Inode Page的空間使用完了，就需要再分配一個inode page，并加入到 FSP_SEG_INODES_FREE 鏈表上( fsp_alloc_seg_inode_page )。對于獨立表空間，通常一個inode page就足夠了。

當拿到目標inode page后，從該Page中找到一個空閑（ fsp_seg_inode_page_find_free ）未使用的slot（空閑表示其不歸屬任何segment，即FSEG_ID置為0）。

一旦該inode page中的記錄用滿了，就從 FSP_SEG_INODES_FREE 鏈表上轉移到 FSP_SEG_INODES_FULL 鏈表。

獲得inode entry后，遞增頭page的 FSP_SEG_ID ，作為當前segment的seg id寫入到inode entry中。隨后進行一些列的初始化。

在完成inode entry的提取后，就將該inode entry所在inode page的位置及頁內偏移量存儲到其他某個page內（對于btree就是記錄在根節點內，占用10個字節，包含space id, page no, offset）。

Btree的根節點實際上是在創建non-leaf segment時分配的，root page被分配到該segment的frag array的第一個數組元素中。

Segment分配入口函數： fseg_create_general

Step 1：空間擴展

當判定插入索引的操作可能引起分裂時，會進行悲觀插入( btr_cur_pessimistic_insert )，在做實際的分裂操作之前，會先對文件進行擴展，并嘗試預留(tree_height / 16 + 3)個Extent，大多數情況下都是3個Extent。

這里有個意外場景：如果當前文件還不超過一個Extent，并且請求的page數小于1/2個Extent時，則如果指定page數，保證有2個可用的空閑Page，或者分配指定的page，而不是以Extent為單位進行分配。

注意這里只是保證有足夠的文件空間，避免在btree操作時進行文件Extent。如果在這一步擴展了ibd文件( fsp_try_extend_data_file )，新的數據頁并未初始化，也未加入到任何的鏈表中。

在判定是否有足夠的空閑Extent時，本身ibd預留的空閑空間也要納入考慮，對于普通用戶表空間是2個Extent + file_size * 1%。這些新擴展的page此時并未進行初始化，也未加入到，在頭page的 FSP_FREE_LIMIT 記錄的page no標識了這類未初始化頁的范圍。

Step 2：為segment分配page

隨后進入索引分裂階段( btr_page_split_and_insert )，新page分配的上層調用棧：

btr_page_alloc
|--> btr_page_alloc_low
    |--> fseg_alloc_free_page_general
            |--> fseg_alloc_free_page_low

在傳遞的參數中，有個hint page no，通常是當前需要分裂的page no的前一個（direction = FSP_DOWN）或者后一個page no(direction = FSP_UP)，其目的是將邏輯上相鄰的節點在物理上也盡量相鄰。

在Step 1我們已經保證了物理空間有足夠的數據頁，只是還沒進行初始化。將page分配到當前segment的流程如下( fseg_alloc_free_page_low )：

1. 計算當前segment使用的和占用的page數
   • 使用的page數存儲包括 FSEG_NOT_FULL 鏈表上使用的page數(存儲在inode entry的 FSEG_NOT_FULL_N_USED 中) + 已用滿segment的 FSEG_FULL 鏈表上page數 + 占用的frag array page數量；
   • 占用的page數包括 FSEG_FREE 、 FSEG_NOT_FULL 、 FSEG_FULL 三個鏈表上的Extent + 占用的frag array page數量。
2. 根據hint page獲取對應的xdes entry ( xdes_get_descriptor_with_space_hdr )
3. 當滿足如下條件時該hint page可以直接拿走使用：
   • Extent狀態為 XDES_FSEG ，表示屬于一個segment
   • hint page所在的Extent已被分配給當前segment(檢查xdes entry的XDES_ID)
   • hint page對應的bit設置為free，表示尚未被占用
   • 返回hint page
4. 當滿足條件：1) xdes entry當前是空閑狀態(XDES_FREE)；2) 該segment中已使用的page數大于其占用的page數的7/8 ( FSEG_FILLFACTOR )；3) 當前segment已經使用了超過32個frag page，即表示其inode中的frag array可能已經用滿。
   • 從表空間分配hint page所在的Extent ( fsp_alloc_free_extent )，將其從FSP_FREE鏈表上移除
   • 設置該Extent的狀態為XDES_FSEG，寫入seg id，并加入到當前segment的FSEG_FREE鏈表中。
   • 返回hint page
5. 當如下條件時：1) direction != FSP_NO_DIR，對于Btree分裂，要么FSP_UP，要么FSP_DOWN；2）已使用的空間小于已占用空間的7/8； 3）當前segment已經使用了超過32個frag page
   • 嘗試從segment獲取一個Extent( fseg_alloc_free_extent )，如果該segment的FSEG_FREE鏈表為空，則需要從表空間分配（ fsp_alloc_free_extent ）一個Extent，并加入到當前segment的FSEG_FREE鏈表上
   • direction為FSP_DOWN時， 返回該Extent最后一個page ，為FSP_UP時， 返回該Extent的第一個Page
6. xdes entry屬于當前segment且未被用滿，從其中取一個 空閑page并返回
7. 如果該segment占用的page數大于實用的page數，說明該segment還有空閑的page，則依次先看 FSEG_NOT_FULL 鏈表上是否有未滿的Extent，如果沒有，再看FSEG_FREE鏈表上是否有完全空閑的Extent。從其中取一個 空閑Page并返回
8. 當前已經實用的Page數小于32個page時，則分配獨立的page（ fsp_alloc_free_page ）并加入到該inode的frag array page數組中，然后 返回該block
9. 當上述情況都不滿足時，直接分配一個Extent( fseg_alloc_free_extent )，并從 其中取一個page返回 。

上述流程看起來比較復雜，但可以總結為：

1. 對于一個新的segment，總是優先填滿32個frag page數組，之后才會為其分配完整的Extent，可以利用碎片頁，并避免小表占用太多空間。
2. 盡量獲得hint page;
3. 如果segment上未使用的page太多，則盡量利用segment上的page。

上文提到兩處從表空間為segment分配數據頁，一個是分配單獨的數據頁，一個是分配整個Extent

表空間單獨數據頁的分配調用函數 fsp_alloc_free_page :

1. 如果hint page所在的Extent在鏈表 XDES_FREE_FRAG 上，可以直接使用；否則從根據頭page的 FSP_FREE_FRAG 鏈表查看是否有可用的Extent；
2. 未能從上述找到一個可用Extent，直接分配一個Extent，并加入到 FSP_FREE_FRAG 鏈表中；
3. 從獲得的Extent中找到描述為空閑（ XDES_FREE_BIT ）的page。
4. 分配該page ( fsp_alloc_from_free_frag )
   • 設置page對應的bitmap的 XDES_FREE_BIT 為false，表示被占用；
   • 遞增頭page的 FSP_FRAG_N_USED 字段；
   • 如果該Extent被用滿了，就將其從 FSP_FREE_FRAG 移除，并加入到 FSP_FULL_FRAG 鏈表中。同時對頭Page的 FSP_FRAG_N_USED 遞減1個Extent( FSP_FRAG_N_USED 只存儲未滿的Extent使用的page數量)；
   • 對Page內容進行初始化( fsp_page_create )。

表空間Extent的分配函數 fsp_alloc_free_extent :

1. 通常先通過頭page看FSP_FREE鏈表上是否有空閑的Extent，如果沒有的話，則將新的Extent（例如上述step 1對文件做擴展產生的新page，從 FSP_FREE_LIMIT 算起）加入到 FSP_FREE 鏈表上( fsp_fill_free_list )：
   • 一次最多加4個Extent( FSP_FREE_ADD )；
   • 如果涉及到xdes page，還需要對xdes page進行初始化；
   • 如果Extent中存在類似xdes page這樣的系統管理頁，這個Extent被加入到 FSP_FREE_FRAG 鏈表中而不是 FSP_FREE 鏈表；
   • 取鏈表上第一個Extent為當前使用；
2. 將獲得的Extent從 FSP_FREE 移除，并返回對應的xdes entry( xdes_lst_get_descriptor )。

當某個數據頁上的數據被刪光時，我們需要從其所在segmeng上刪除該page（ btr_page_free -->fseg_free_page --> fseg_free_page_low ），回收的流程也比較簡單：

1. 首先如果是該segment的frag array中的page，將對應的slot設置為FIL_NULL, 并返還給表空間( fsp_free_page ):
   • page在xdes entry中的狀態置為空閑；
   • 如果page所在Extent處于 FSP_FULL_FRAG 鏈表，則轉移到 FSP_FREE_FRAG 中；
   • 如果Extent中的page完全被釋放掉了，則釋放該Extent( fsp_free_extent )，將其轉移到FSP_FREE鏈表；
   • 從函數 返回 ；
2. 如果page所處于的Extent當前在該segment的FSEG_FULL鏈表上，則轉移到 FSEG_NOT_FULL 鏈表；
3. 設置Page在xdes entry的bitmap對應的XDES_FREE_BIT為true；
4. 如果此時該Extent上的page全部被釋放了，將其從 FSEG_NOT_FULL 鏈表上移除，并加入到表空間的 FSP_FREE 鏈表上(而非Segment的 FSEG_FREE 鏈表)。

由于數據操作都需要記錄redo，為了避免產生非常大的redo log，leaf segment通過反復調用函數 fseg_free_step 來釋放其占用的數據頁：

1. 首先找到leaf segment對應的Inode entry（ fseg_inode_try_get ）；
2. 然后依次查找inode entry中的 FSEG_FULL 、或者 FSEG_NOT_FULL 、或者 FSEG_FREE 鏈表，找到一個Extent，注意著里的鏈表元組所指向的位置實際上是描述該Extent的Xdes Entry所在的位置。因此可以快速定位到對應的Xdes Page及Page內偏移量( xdes_lst_get_descriptor )；
3. 現在我們可以將這個Extent安全的釋放了( fseg_free_extent ，見后文)；
4. 當反復調用 fseg_free_step 將所有的Extent都釋放后，segment還會最多占用32個碎片頁，也需要依次釋放掉( fseg_free_page_low )
5. 最后，當該inode所占用的page全部釋放時，釋放inode entry：
   • 如果該inode所在的inode page中當前被用滿，則由于我們即將釋放一個slot，需要從 FSP_SEG_INODES_FULL 轉移到 FSP_SEG_INODES_FREE （更新第一個page）；
   • 將該inode entry的SEG_ID清除為0，表示未使用；
   • 如果該inode page上全部inode entry都釋放了，就從 FSP_SEG_INODES_FREE 移除，并刪除該page。

non-leaf segment的回收和leaf segment的回收基本類似，但要注意btree的根節點存儲在該segment的frag arrary的第一個元組中，該Page暫時不可以釋放( fseg_free_step_not_header )

btree的root page在完成上述步驟后再釋放，此時才能徹底釋放non-leaf segment

索引頁

ibd文件中真正構建起用戶數據的結構是BTREE，在你創建一個表時，已經基于顯式或隱式定義的主鍵構建了一個btree，其葉子節點上記錄了行的全部列數據（加上事務id列及回滾段指針列）；如果你在表上創建了二級索引，其葉子節點存儲了鍵值加上聚集索引鍵值。本小節我們探討下組成索引的物理存儲頁結構，這里默認討論的是非壓縮頁，我們在下一小節介紹壓縮頁的內容。

每個btree使用兩個Segment來管理數據頁，一個管理葉子節點，一個管理非葉子節點，每個segment在inode page中存在一個記錄項，在btree的root page中記錄了兩個segment信息。

當我們需要打開一張表時，需要從ibdata的數據詞典表中load元數據信息，其中SYS_INDEXES系統表中記錄了表，索引，及索引根頁對應的page no（ DICT_FLD__SYS_INDEXES__PAGE_NO ），進而找到btree根page，就可以對整個用戶數據btree進行操作。

索引最基本的頁類型為 FIL_PAGE_INDEX 。可以劃分為下面幾個部分。

10個字節的inode信息包括：

通過上述信息，我們可以找到對應segment在inode page中的描述項，進而可以操作整個segment。

Compact的系統記錄存儲方式為：

兩種格式的主要差異在于不同行存儲模式下，單個記錄的描述信息不同。在實際創建page時，系統記錄的值已經初始化好了，對于老的格式(REDUNDANT)，對應代碼里的 infimum_supremum_redundant ，對于新的格式(compact)，對應 infimum_supremum_compact 。infimum記錄的固定heap no為0，supremum記錄的固定Heap no 為1。page上最小的用戶記錄前節點總是指向infimum，page上最大的記錄后節點總是指向supremum記錄。

具體參考索引頁創建函數： page_create_low

根據不同的類型，用戶記錄可以是非葉子節點的Node指針信息，也可以是只包含有效數據的葉子節點記錄。而不同的行格式存儲的行記錄也不同，例如在早期版本中使用的redundant格式會被現在的compact格式使用更多的字節數來描述記錄，例如描述記錄的一些列信息，在使用compact格式時，可以改為直接從數據詞典獲取。因為redundant屬于漸漸被拋棄的格式，本文的討論中我們默認使用Compact格式。在文件rem/rem0rec.cc的頭部注釋描述了記錄的物理結構。

每個記錄都存在rec header，描述如下（參閱文件include/rem0rec.ic）

在記錄頭信息之后的數據視具體情況有所不同：

• 對于聚集索引記錄，數據包含了事務id，回滾段指針；
• 對于二級索引記錄，數據包含了二級索引鍵值以及聚集索引鍵值。如果二級索引鍵和聚集索引有重合，則只保留一份重合的，例如pk (col1, col2)，sec key(col2, col3)，在二級索引記錄中就只包含(col2, col3, col1);
• 對于非葉子節點頁的記錄，聚集索引上包含了其子節點的最小記錄鍵值及對應的page no；二級索引上有所不同，除了二級索引鍵值外，還包含了聚集索引鍵值，再加上page no三部分構成。

Page Directory的slot分配是從Page末尾（倒數第八個字節開始）開始逆序分配的。在查詢記錄時。先根據page directory 確定記錄所在的范圍，然后在據此進行線性查詢。

增加slot的函數參閱 page_dir_add_slot

頁內記錄二分查找的函數參閱 page_cur_search_with_match_bytes

壓縮索引頁

InnoDB當前存在兩種形式的壓縮頁，一種是Transparent Page Compression，還有一種是傳統的壓縮方式，下文分別進行闡述。

Transparent Page Compression

這是MySQL5.7新加的一種數據壓縮方式，其原理是利用內核Punch hole特性，對于一個16kb的數據頁，在寫文件之前，除了Page頭之外，其他部分進行壓縮，壓縮后留白的地方使用punch hole進行 “打洞”，在磁盤上表現為不占用空間 （但會產生大量的磁盤碎片）。 這種方式相比傳統的壓縮方式具有更好的壓縮比，實現邏輯也更加簡單。

對于這種壓縮方式引入了新的類型 FIL_PAGE_COMPRESSED ，在存儲格式上略有不同，主要表現在從 FIL_PAGE_FILE_FLUSH_LSN 開始的8個字節被用作記錄壓縮信息：

打洞后的page其實際存儲空間需要是磁盤的block size的整數倍。

這里我們不展開闡述，具體參閱我之前寫的這篇文章： MySQL · 社區動態 · InnoDB Page Compression

傳統壓縮存儲格式

當你創建或修改表，指定 row_format=compressed key_block_size=1|2|4|8 時，創建的ibd文件將以對應的block size進行劃分。例如 key_block_size 設置為4時，對應block size為4kb。

壓縮頁的格式可以描述如下表所示：

在內存中通常存在壓縮頁和解壓頁兩份數據。當對數據進行修改時，通常先修改解壓頁，再將DML操作以一種特殊日志的格式記入壓縮頁的mlog中。以減少被修改過程中重壓縮的次數。主要包含這幾種操作：

• Insert: 向mlog中寫入完整記錄
• Update:
  • Delete-insert update，將舊記錄的dense slot標記為刪除，再寫入完整新記錄
  • In-place update，直接寫入新更新的記錄
• Delete: 標記對應的dense slot為刪除

頁壓縮參閱函數 page_zip_compress
頁解壓參閱函數 page_zip_decompress

系統數據頁

這里我們將所有非獨立的數據頁統稱為系統數據頁，主要存儲在ibdata中，如下圖所示：

InnoDB 系統數據頁

ibdata的三個page和普通的用戶表空間一樣，都是用于維護和管理文件頁。其他Page我們下面一一進行介紹。

IBUF HEADER Page 和Root Page聯合起來對ibuf的數據頁進行管理。

首先Ibuf btree自己維護了一個空閑Page鏈表，鏈表頭記錄在根節點中，偏移量在 PAGE_BTR_IBUF_FREE_LIST 處，實際上利用的是普通索引根節點的 PAGE_BTR_SEG_LEAF 字段。Free List上的Page類型標示為 FIL_PAGE_IBUF_FREE_LIST

每個Ibuf page重用了 PAGE_BTR_SEG_LEAF 字段，以維護IBUF FREE LIST的前后文件頁節點（ PAGE_BTR_IBUF_FREE_LIST_NODE ）。

由于root page中的segment字段已經被重用，因此額外的開辟了一個Page，也就是Ibdata的第4個page來進行段管理。在其中記錄了ibuf btree的segment header，指向屬于ibuf btree的inode entry。

關于ibuf btree的構建參閱函數 btr_create

在5.7版本中，回滾段既可以在ibdata中，也可以在獨立undo表空間，或者ibtmp臨時表空間中，一個可能的分布如下圖所示（摘自我之前的這篇文章）。

InnoDB Undo 回滾段結構

由于是在系統剛啟動時初始化事務系統，因此第0號回滾段頭頁總是在ibdata的第7個page中。

事務系統創建參閱函數 trx_sysf_create

InnoDB最多可以創建128個回滾段，每個回滾段需要單獨的Page來維護其擁有的undo slot，Page類型為 FIL_PAGE_TYPE_SYS 。描述如下：

回滾段頭頁的創建參閱函數 trx_rseg_header_create

實際存儲undo記錄的Page類型為 FIL_PAGE_UNDO_LOG ，undo header結構如下

undo頁內結構及其與回滾段頭頁的關系參閱下圖：

InnoDB Undo 頁內結構

關于具體的Undo log如何存儲，本文不展開描述，可閱讀我之前的這篇文章： MySQL · 引擎特性 · InnoDB undo log 漫游

Dict_Hdr Page的結構如下表所示：

dict_hdr頁的創建參閱函數 dict_hdr_create

double write buffer存儲在ibdata中，你可以從事務系統頁(ibdata的第6個page)獲取dblwr所在的位置。總共128個page，劃分為兩個block。由于dblwr在安裝實例時已經初始化好了，這兩個block在Ibdata中具有固定的位置，Page64 ~127 劃屬第一個block，Page 128 ~191劃屬第二個block。

在這128個page中，前120個page用于batch flush時的臟頁回寫，另外8個page用于SINGLE PAGE FLUSH時的臟頁回寫。

外部存儲頁

對于大字段，在滿足一定條件時InnoDB使用外部頁進行存儲。外部存儲頁有三種類型：

1. FIL_PAGE_TYPE_BLOB ：表示非壓縮的外部存儲頁，結構如下圖所示：

   

2. FIL_PAGE_TYPE_ZBLOB ：壓縮的外部存儲頁，如果存在多個blob page，則表示第一個

   FIL_PAGE_TYPE_ZBLOB2 ：如果存在多個壓縮的blob page，則表示blob鏈隨后的page；

   結構如下圖所示：

   

而在記錄內只存儲了20個字節的指針以指向外部存儲頁，指針描述如下：

外部頁的寫入參閱函數 btr_store_big_rec_extern_fields

MySQL5.7新數據頁：加密頁及R-TREE頁

MySQL 5.7版本引入了新的數據頁以支持表空間加密及對空間數據類型建立R-TREE索引。本文對這種數據頁不做深入討論，僅僅簡單描述下，后面我們會單獨開兩篇文章分別進行介紹。

• FIL_PAGE_ENCRYPTED ：加密的普通數據頁
• FIL_PAGE_COMPRESSED_AND_ENCRYPTED ：數據頁為壓縮頁(transparent page compression) 并且被加密（先壓縮，再加密）
• FIL_PAGE_ENCRYPTED_RTREE ：GIS索引R-TREE的數據頁并被加密

對于加密頁，除了數據部分被替換成加密數據外，其他部分和大多數表都是一樣的結構。

加解密的邏輯和Transparent Compression類似，在寫入文件前加密( os_file_encrypt_page --> Encryption::encrypt )，在讀出文件時解密數據( os_file_io_complete --> Encryption::decrypt )

秘鑰信息存儲在ibd文件的第一個page中（ fsp_header_init --> fsp_header_fill_encryption_info ），當執行SQL ALTER INSTANCE ROTATE INNODB MASTER KEY 時，會更新每個ibd存儲的秘鑰信息( fsp_header_rotate_encryption )

默認安裝時，一個新的插件 keyring_file 被安裝并且默認Active，在安裝目錄下，會產生一個新的文件來存儲秘鑰，位置在$MYSQL_INSTALL_DIR/keyring/keyring，你可以通過參數 keyring_file_data 來指定秘鑰的存放位置和文件命名。 當你安裝多實例時，需要為不同的實例指定keyring文件。

開啟表加密的語法很簡單，在CREATE TABLE或ALTER TABLE時指定選項ENCRYPTION=‘Y’來開啟，或者ENCRYPTION=‘N’來關閉加密。

關于InnoDB表空間加密特性，參閱該 commit 及 官方文檔 。

R-TREE的相關設計參閱官方 WL#6968 ， WL#6609 , WL#6745

臨時表空間ibtmp

MySQL5.7引入了臨時表專用的表空間，默認命名為ibtmp1，創建的非壓縮臨時表都存儲在該表空間中。系統重啟后，ibtmp1會被重新初始化到默認12MB。你可以通過設置參數 innodb_temp_data_file_path 來修改ibtmp1的默認初始大小，以及是否允許autoExtent。默認值為 “ibtmp1:12M:autoExtent”。

除了用戶定義的非壓縮臨時表外，第1~32個臨時表專用的回滾段也存放在該文件中（0號回滾段總是存放在ibdata中）( trx_sys_create_noredo_rsegs )，

日志文件ib_logfile

關于日志文件的格式，網上已經有很多的討論，在之前的系列文章中我也有專門介紹過，本小節主要介紹下MySQL5.7新的修改。

首先是checksum算法的改變，當前版本的MySQL5.7可以通過參數 innodb_log_checksums 來開啟或關閉redo checksum，但目前唯一支持的checksum算法是CRC32。而在之前老版本中只支持效率較低的InnoDB本身的checksum算法。

第二個改變是為Redo log引入了版本信息( WL#8845 )，存儲在ib_logfile的頭部，從文件頭開始，描述如下

每次切換到下一個iblogfile時，都會更新該文件頭信息( log_group_file_header_flush )

新的版本支持兼容老版本（ recv_find_max_checkpoint_0 ），但升級到新版本后，就無法在異常狀態下in-place降級到舊版本了（除非做一次clean的shutdown，并清理掉iblogfile）。

具體實現參閱該 commit 。