InnoDB資料頁結構

前言

​ 關於資料庫我們知道是通過記憶體對磁碟進行操作的，也知道資料會落實到磁碟上，但是資料在磁碟上的儲存結構可能大家還不是很清楚。

​ MySQL伺服器上負責對錶中的資料的讀取和寫入的工作的部分是儲存引擎，而關於伺服器會支援不同型別的伺服器，如：InnoDB、MyISAM、Memory......

​ 不同的儲存引擎都是為了實現不同的特性進行開發的，真實資料的儲存在不同的儲存引擎中存放的格式一般是不同的，有的儲存引擎比如Memory都不用磁碟來儲存資料，就跟NoSQL一樣，伺服器關閉後資料就不見了。InnoDB是MySQL的預設儲存引擎，也是我們大家常用的儲存引擎。

​ Mysql把頁作為管理儲存空間的基本單位，一個頁的大小一般是16KB，大家知道記錄其實是被儲存在頁中的，本文將詳細的帶大家看一下InnoDB儲存引擎中頁的結構。

---

引用

​ 參考文章：InnoDB資料頁結構

---

InnoDB頁

簡介

​ InnoDB是一個將表中的資料儲存到磁碟上的儲存引擎，所以即使關機後重啟我們的資料還是存在的。而真正處理資料的過程是發生在記憶體中的，所以需要把磁碟中的資料載入到記憶體中，如果是處理寫入或修改請求的話，還需要把記憶體中的內容重新整理到磁碟上。而我們知道讀寫磁碟的速度非常慢，和記憶體讀寫之間的差距就不再多說，所以當我們想從表中獲取某些記錄時，InnoDB儲存引擎需要一條一條的把記錄從磁碟上讀出來麼？不，那樣會慢死，InnoDB採取的方式是：將資料劃分為若干個頁，以頁作為磁碟和記憶體之間互動的基本單位，InnoDB中頁的大小一般為 16KB。也就是在一般情況下，一次最少從磁碟中讀取16KB的內容到記憶體中，一次最少把記憶體中的16KB內容重新整理到磁碟中。

頁結構

​ 頁的本質介紹一個大小為16KB大小的儲存空間，頁有很多種型別的，不同的型別有不同的作用；

​ 用於儲存記錄的頁被稱為資料頁 ，大小也為16KB，但是這16KB大小的儲存空間被劃分為多個部分，不同的部分當然有著不同的功能，結構如下：

​ 從上面的圖可以看到，InnoDB的頁結構分為七個部分，下面用表格說明一下各個部分對應的作用：

名稱	中文名	佔用空間大小	簡單描述
File Header	檔案頭	38位元組	描述頁的資訊
Page Header	頁頭	56位元組	頁的狀態資訊
Infimum + SupreMum	最小記錄和最大記錄	26位元組	兩個虛擬的行記錄（後面會說明）
User Records	使用者記錄	不確定	實際儲存的行記錄內容
Free Space	空閒空間	不確定	頁中尚未使用的空間
Page Directory	頁目錄	不確定	頁中的記錄相對位置
File Trailer	檔案結尾	8位元組	結尾資訊

​ 下面會詳細介紹他們的作用

---

頁中的儲存

​ 當我們在儲存資料的時候，記錄會儲存到User Records部分 。但是在一個頁新形成的時候是不存在User Records 這個部分的，每當我們在插入一條記錄的時候，都會從Free Space中去申請一塊大小符合該記錄大小的空間並劃分到User Records，當Free Space的部分空間全部被User Records部分替換掉之後，就意味著當前頁使用完畢，如果還有新的記錄插入，需要再去申請新的頁，過程如下：

記錄頭

​ 對於User Records中的每一條記錄的管理，MySQL做了很多的處理，究竟做出了什麼處理呢，這需要從每條記錄裡面的記錄的額外資訊部分中的記錄頭資訊說起 這是有關行格式的知識，關於行格式（指的就是一條記錄的儲存結構，有多種格式），有興趣的可以去看一下InnoDB記錄儲存結構 這篇文章。

​ 首先，建立一個表：

mysql> CREATE TABLE page_demo(
    ->     c1 INT,
    ->     c2 INT,
    ->     c3 VARCHAR(10000),
    ->     PRIMARY KEY (c1)
    -> ) CHARSET=ascii ROW_FORMAT=Compact;
Query OK, 0 rows affected (0.03 sec)
mysql>
複製程式碼

​ 如上所示，表中有三列，c1和c2用來儲存整數的，c3用來儲存字串的。因為指定了主鍵為c1，所以MySQL就不會去建立那個隱藏的 row_id 列。指定了ascii字符集以及Compact的行格式，所以裡面的每一條記錄的行格式如下：

​ 先看一下行格式中每個屬性代表的意思：

​

名稱	大小（單位：bit）	描述
預留位1	1	沒有使用
預留位2	1	沒有使用
delete_mask	1	標記該記錄是否被刪除
min_rec_mask	1	標記該記錄是否為B+樹的非葉子節點中的最小記錄（索引時用到）
n_owned	4	表示當前槽管理的記錄數
heap_no	13	表示當前記錄在記錄堆的位置資訊
record_type	3	表示當前記錄的型別，0表示普通記錄，1表示B+樹非葉節點記錄，2表示最小記錄，3表示最大記錄
next_record	16	表示下一條記錄的相對位置

​ 由於這裡只是描述在User Records中記錄頭的作用，所以下面只會說明一些相關的屬性以及c1、c2、c3列的資訊（其他資訊沒畫不代表它們不存在，只是為了理解上的方便省略了～），簡化後的行格式示意圖就是這樣：

​ 我們往表中插入幾條資料：

mysql> INSERT INTO page_demo VALUES(1, 100, 'aaaa'), (2, 200, 'bbbb'), (3, 300, 'cccc'), (4, 400, 'dddd');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql>
複製程式碼

​ 下面看看幾條記錄在頁中的User Records是以何種形式進行體現的，為了方便理解，下面的圖中把記錄中的頭資訊和實際的資料都用的十進位制進行的表示（其實都是二進位制）：

​

​ 下面說說，記錄頭中的各個部分代表的含義：

delete_mask

​ 這個屬性說的是當前這條記錄是否被刪除，當值為0的時候代表著沒有被刪除，為1的時候標誌著被刪除了。

是的，您沒看錯，當您執行刪除一個記錄的操作的時候，被刪除的記錄還存在頁中，您對它進行了刪除，它會把的

記錄頭中的這個屬性設定為1，只是打了個標記。

原因

這些被刪除的記錄之所以不立即從磁碟上移除，是因為移除它們之後把其他的記錄在磁碟上重新排列需要效能消耗，所以只是打個刪除標記而已，而且這部分儲存空間之後還可以重用，也就是說之後如果有新記錄插入到表中的話，可能把這些被刪除的記錄佔用的儲存空間覆蓋掉。

如果您想徹底的從磁碟上移除這些被刪除的記錄，可以使用這個語句：

optimize table '表名';
複製程式碼

執行這個命令後伺服器會重新規劃表中記錄的儲存方式，把被標記為刪除的記錄從磁碟上移除。

min_rec_mask

​ 有關索引的，暫時不說，後面說到索引會說明；

n_owned

​ 下面會講

heap_no

​ 這個屬性是表示的當前記錄在當前頁中的位置，上面的一張圖如果您仔細看了的話，會發現它們的位置分別是2、3、4、5，那麼問題來了？ 0和1呢？

​ 這是因為在每次建立的一頁裡面會自動的加入兩條記錄，這被稱為偽記錄 或者 虛擬記錄 （因為不是我們自己插入的）;

​ 這兩條偽記錄一個代表著最小記錄，一個代表著最大記錄 ；

​ 記錄大小的比較是通過主鍵值來比較的。在上面我們插入的幾條記錄中的從小到大的順序就是：1 < 2 < 3 < 4,

這標誌著這4條記錄的大小依次遞增。

​ 不管我們插入了什麼資料，頁中的最小記錄 和 最大記錄 都是頁生成時候的那兩條偽記錄。這兩條偽記錄的結構頁相對簡單，如下：

​

​ 還記得頁結構組成的七部分中一個部分叫Infimum + SupreMum ，這個部分用來儲存最小記錄和最大記錄的，沒錯，就是這兩條偽記錄。

原因：由於這兩條記錄不是我們自己定義的記錄，所以它們並不存放在頁的User Records部分，他們被單獨放在一個稱為Infimum + Supremum的部分

​

​ 由上面的圖可以看出，最小記錄和最大記錄的heap_no的值分別為0和1，也就是說它們的位置最靠前。

record_type

​ 這個屬性表示當前記錄的型別，一共有4種型別的記錄，0表示普通記錄，1表示B+樹非葉節點記錄，2表示最小記錄，3表示最大記錄。從圖中我們也可以看出來，我們自己插入的記錄就是普通記錄，它們的record_type值都是0，而最小記錄和最大記錄的record_type值分別為2和3 ，關於1暫且不說；

next_record

​ 這個屬性表示這從當前記錄真實資料到下一條記錄的真實資料的地址偏移量 ；

​ 假如有一條記錄的next_record 的值為12，就標誌著從這條記錄的真實資料的地址往後找12個位元組就是下一條記錄的真實資料（連結串列）。也就是說頁中的資料之間的聯絡是一個根據大小比較後從小指到大的單向連結串列。

​ 規定 最小記錄 的下一條記錄就本頁中主鍵值最小的記錄，而本頁中主鍵值最大的記錄的下一條記錄就是 最大記錄(最大的那條偽記錄) ，為了更形象的表示一下這個next_record起到的作用，我們用箭頭來替代一下next_record中的地址偏移量：

​

​ 從上面可以看出，最大記錄 的 next_record 的值為0，代表著最大記錄的下一條記錄是不存在的，它也是鏈條中的最後一個節點。

​ 當我們從頁中刪除一條資料後可以看看連結串列會發生那些變化：

mysql> DELETE FROM page_demo WHERE c1 = 2;
Query OK, 1 row affected (0.02 sec)

mysql>
複製程式碼

​ 刪掉第2條記錄後的示意圖就是：

​

​ 從上面可以看到：

當我們刪除第二條記錄後，連結串列中的變化最明顯的就是各個節點之間的聯絡，它會把被刪除資料的上一條記錄和被刪除資料的下一條資料進行關聯（這條資料還是存在的，之前說的那個刪除標記別忘了哦）。

• 第2條記錄並沒有從儲存空間中移除，而是把該條記錄的delete_mask值設定為1。
• 第2條記錄的next_record值變為了0，意味著該記錄沒有下一條記錄了。
• 第1條記錄的next_record指向了第3條記錄。
• 還有一點您可能忽略了，就是最大記錄的n_owned值從5變成了4，關於這一點的變化我們稍後會詳細說明的。

所以得到：不論我們怎麼對頁中的記錄做增刪改操作，InnoDB始終會維護一條記錄的單連結串列，連結串列中的各個節點是按照主鍵值由小到大的順序連線起來的。

​

​ 下面我們再做一個操作，把刪除的記錄再次插入：

mysql> INSERT INTO page_demo VALUES(2, 200, 'bbbb');
Query OK, 1 row affected (0.00 sec)

mysql>
複製程式碼

​ 我們來看看發生了什麼變化：

​

​ 很明顯的可以看到，InnoDB並沒有因為新記錄的插入而為它申請新的儲存空間，而是直接複用了原來被刪除記錄的儲存空間。

Page Directory

​ 通過上面，我們知道到了頁中記錄是一個按照大小從下到大連續的單向連結串列，現在來想想，當我們根據主鍵查詢一條記錄的時候是怎樣進行的，我們來看看;

SELECT * FROM page_demo WHERE c1 = 3;
複製程式碼

​ 上面是一條查詢語句，我們想想它的執行方式可能是：

​ 從最小記錄開始，沿著連結串列一直往後找，總有一天會找到（或者找不到），在找的時候還能投機取巧，因為連結串列中各個記錄的值是按照從小到大順序排列的，所以當連結串列的某個節點代表的記錄的主鍵值大於您想要查詢的主鍵值時，如果這個時候還沒找到資料的話您就可以停止查詢了（代表找不到），因為該節點後邊的節點的主鍵值都是依次遞增。

​ 上面的方式存在的問題就是，當頁中的儲存的記錄數量比較少的情況用起來也沒啥問題，但是如果一個頁中儲存了非常多的記錄，這麼查詢對效能來說還是有損耗的，所以這個方式很笨啊。

​ 我們來看看InnoDB 的處理方式：InnoDB 的處理方式相當於我們平時看書的時候，想看那一章的時候不會傻到去一頁一頁的找，而是通過目錄去找到對應的頁數，直接就定位過去了。說說InnoDB 這樣處理的步驟吧：

​ 1. 將所有正常的記錄（包括最大和最小記錄，不包括標記為已刪除的記錄）劃分為幾個組。

​ 2. 每個組的最後一條記錄的頭資訊中的n_owned屬性表示該組內共有幾條記錄。

​ 3. 將每個組的最後一條記錄的地址偏移量按順序儲存起來，每個地址偏移量也被稱為一個槽（英文名：Slot）。這些地址偏移量都會被儲存到靠近頁的尾部的地方，頁中儲存地址偏移量的部分也被稱為Page Directory 。

​

​ 比如說，現在表中有6條記錄，InnoDB會把它們分成兩組，第一組中只有一個最小記錄，第二組中是剩餘的5條記錄，看下邊的示意圖：

​

​ 從上面的圖中可以看到：

• Page Directory中有兩個槽，也就是兩個組，槽0的值是90，代表最小記錄的地址偏移量；槽2的值是112，代表最大記錄的地址偏移量；
• 注意記錄中的最小記錄和最大記錄，他們分別是1和5：
  • 最小記錄的n_owned 的值為1，代表著以最小記錄結尾的這個分組中只有1條記錄，就是最小記錄本身；
  • 同理，最大記錄的n_owned 的值為5，代表著以最大記錄結尾的這個分組中只有5條記錄，這5條記錄包括它本身，就是說除了它本身還有其它4條記錄；

​ 我們用圖來表示一下：

​

​ 上面的圖中為了方便理解，暫時沒管各條記錄在儲存裝置上的排列方式了，單純從邏輯上看一下這些記錄和頁目錄的關係。真實的Page Directory 是在下面的。

​ 再說說，為什麼最小記錄的n_owned值為1，而最大記錄的n_owned值為5呢？它們是怎麼分配的？

​ InnoDB 對每個分組中的記錄條數是有規定的，對於最小記錄所在的分組只能有 1 條記錄，最大記錄所在的分組擁有的記錄條數只能在 1~8 條之間，剩下的分組中記錄的條數範圍只能在是 4~8 條之間。所以分組是按照下邊的步驟進行的：

• 初始情況下一個資料頁裡面只有最小記錄和最大記錄（偽記錄），它們屬於不同的分組，也就是兩個；
• 之後插入的每一條記錄都會放到最大記錄所在的組，直到最大記錄所在組的記錄數等於8條；
• 當最大記錄所在組中的記錄數等於8條的時候，如果還有記錄插入的話，就會將最大記錄所在組平均分裂成2個組，這個時候最大記錄所在組就只剩下4條記錄，這裡再把這條記錄再放入最大記錄所在組；

​ 我們一口氣又往表中新增了12條記錄，現在就一共有16條正常的記錄了（包括最小和最大記錄），這些記錄被分成了5個組，如圖所示：

​

​ 上圖中，只保留了頭資訊中的n_owned和next_record屬性，也省略了各個記錄之間的箭頭，沒畫不等於沒有！

​ 因為各個槽代表的記錄的主鍵值都是從小到大排序的，所以我們可以使用二分法來進行快速查詢。4個槽的編號分別是：0、1、2、3、4，所以初始情況下最低的槽就是low=0，最高的槽就是high=4。比方說我們想找主鍵值為5的記錄，現在我們再來看看查詢一條記錄的步驟：

​ 1. 首先得到中間槽的位置：(0 + 4)/2 = 2 ,所以得到槽2，根據槽2的地址偏移量知道它的主鍵值是8，因為8>5，設定high=2 ，low不變；

​ 2. 再次計算中間槽的位置：(0 + 2)/2 = 1 ,所以得到槽1，根據槽1的地址偏移量知道它的主鍵值是4, 因為4<5，設定low=1 ，high不變；

​ 3. 因為high - low的值為1，所以確定主鍵值為5的記錄在槽1和槽2之間，接下來就是遍歷連結串列的查詢了；

​

​ 所以在一個資料頁中查詢指定主鍵值的記錄的過程分為兩步：

1. 通過二分法確定該記錄所在的槽。

2. 通過記錄的next_record屬性組成的連結串列遍歷查詢該槽中的各個記錄。
複製程式碼

Page Header

​ 設計InnoDB的大叔們為了能得到一個資料頁中儲存的記錄的狀態資訊，比如本頁中已經儲存了多少條記錄，第一條記錄的地址是什麼，Page Directory中儲存了多少個槽等等，特意在頁中定義了一個叫Page Header的部分，它是頁結構的第二部分，這個部分佔用固定的56個位元組，專門儲存各種狀態資訊，具體各個位元組都是幹嘛的看下錶：

​

名稱	大小（單位：byte）
PAGE_N_DIR_SLOTS	2	在頁目錄中的槽數量
PAGE_HEAP_TOP	2	第一個記錄的地址
PAGE_N_HEAP	2	本頁中的記錄的數量（包括最小和最大記錄以及標記為刪除的記錄）
PAGE_FREE	2	指向可重用空間的地址（就是標記為刪除的記錄地址）
PAGE_GARBAGE	2	已刪除的位元組數，行記錄結構中delete_flag為1的記錄大小總數
PAGE_LAST_INSERT	2	最後插入記錄的位置
PAGE_DIRECTION	2	最後插入的方向
PAGE_N_DIRECTION	2	一個方向連續插入的記錄數量
PAGE_N_RECS	2	該頁中記錄的數量（不包括最小和最大記錄以及被標記為刪除的記錄）
PAGE_MAX_TRX_ID	2	修改當前頁的最大事務ID，該值僅在二級索引中定義
PAGE_LEVEL	2	當前頁在索引樹中的位置，高度
PAGE_INDEX_ID	8	索引ID，表示當前頁屬於哪個索引
PAGE_BTR	10	非葉節點所在段的segment header，僅在B+樹的Root頁定義
PAGE_LEVEL	10	B+樹所在段的segment header，僅在B+樹的Root頁定義

​ 如果大家認真看過前邊的文章，那麼大致能看明白這裡頭前邊一半左右的狀態資訊的意思，剩下的狀態資訊看不明白不要著急，飯要一口一口吃，東西要一點一點學。在這裡想強調以下PAGE_DIRECTION和PAGE_N_DIRECTION的意思。

• PAGE_DIRECTION

  假如新插入的一條記錄的主鍵值比上一條記錄的主鍵值比上一條記錄大，我們說這條記錄的插入方向是右邊，反之則是左邊。用來表示最後一條記錄插入方向的狀態就是PAGE_DIRECTION。

• PAGE_N_DIRECTION

  假設連續幾次插入新記錄的方向都是一致的，InnoDB會把沿著同一個方向插入記錄的條數記下來，這個條數就用PAGE_N_DIRECTION這個狀態表示。當然，如果最後一條記錄的插入方向改變了的話，這個狀態的值會被清零重新統計。

File Header

​ 如果說Page Header描述的是頁內的各種狀態資訊，比方說頁裡頭有多少個記錄了呀，有多少個槽了呀，那麼File Header描述的就是頁外的各種狀態資訊，比方說這個頁的編號是多少，它的上一個頁、下一個頁是誰啦。File Header是InnoDB頁的第一部分，這個部分佔用固定的38個位元組，下邊我們看看這個部分的各個位元組都是代表啥意思吧：

名稱	大小（單位：byte）	描述
FIL_PAGE_SPACE_OR_CHKSUM	4	頁的校驗和（checksum值）
FIL_PAGE_OFFSET	4	頁號
FIL_PAGE_PREV	4	上一個頁的頁號
FIL_PAGE_NEXT	4	下一個頁的頁號
FIL_PAGE_LSN	8	最後被修改的日誌序列位置（英文名是：Log Sequence Number）
FIL_PAGE_TYPE	2	該頁的型別（之前我們說的是資料頁）
FIL_PAGE_FILE_FLUSH_LSN	8	僅在系統表空間的一個頁中定義，代表檔案至少被更新到了該LSN值，獨立表空間中都是0
FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID	4	頁屬於哪個表空間

​ 對照著這個表格，我們看幾個目前比較重要的部分：

• FIL_PAGE_SPACE_OR_CHKSUM

  這個代表當前頁面的校驗和（checksum）。啥是個校驗和？就是對於一個很長很長的位元組串來說，我們會通過某種演算法來計算一個值，這個值就稱為校驗和。這樣在比較兩個很長的位元組串之前先比較這兩個長位元組串的校驗和，如果校驗和都不一樣兩個長位元組串肯定是不同的（hashCode和equals），所以省去了直接比較兩個比較長的位元組串的時間損耗(和後面的File Trailer裡面的那個相對應，看到後面您就明白了)。

• FIL_PAGE_OFFSET

  每一個頁都有一個單獨的頁號，就跟您的身份證號碼一樣，InnoDB通過頁號來可以唯一定位一個頁。

• FIL_PAGE_TYPE

  這個代表當前頁的型別，我們前邊說過，InnoDB為了不同的目的而把頁分為不同的型別，本集中介紹的其實都是儲存記錄的資料頁，其實還有很多別的型別的頁：

• FIL_PAGE_PREV和FIL_PAGE_NEXT

  一張表中可以有成千上萬條記錄，一個頁只有16KB，所以可能需要好多頁來存放資料，FIL_PAGE_PREV和FIL_PAGE_NEXT就分別代表本頁的上一個和下一個頁的頁號（雙向連結串列）。​

  

  Page Header 的其它屬性就不說了；

File Trailer

​ 對於這個部分，我的理解比較簡單，我們知道InnoDB 會把資料從記憶體重新整理到磁碟，中間互動的單位是頁 ，但是我們想想，假如再重新整理到磁碟的時候出現了問題，這樣的話怎麼辦呢？

​ 這就是File Trailer 作用，這個部分由8個位元組組成，可以分成2個小部分：

• 前四個位元組代表頁的檢驗和：
  • 這個部分是和File Header中的校驗和相對應的。每當一個頁面在記憶體中修改了，在同步之前就要把它的校驗和算出來，因為File Header在頁面的前邊，所以校驗和會被首先同步到磁碟，當完全寫完時，校驗和也會被寫到頁的尾部，如果完全同步成功，則頁的首部和尾部的校驗和應該是一致的，反之意味著同步中間出了錯；
• 後四個位元組代表日誌序列位置（LSN）
  • 這個部分也是為了校驗頁的完整性的，可以先不用管這個屬性。

總結

1. InnoDB為了不同的目的而設計了不同型別的頁，用於存放我們記錄的頁也叫做`資料頁`。
2. 一個資料頁可以被分為7個部分，分別是
 - `File Header`，表示檔案頭，佔固定的38位元組。
 - `Page Header`，表示頁裡的一些狀態資訊，佔固定的56個位元組。
 - `Infimum + Supremum`，兩個虛擬的偽記錄，分別表示頁中的最小和最大記錄，佔固定的`26`個位元組。
 - `User Records`：真實儲存我們插入的記錄的部分，大小不固定。
 - `Free Space`：頁中尚未使用的部分，大小不確定。
 - `Page Directory`：頁中的記錄相對位置，也就是各個槽在頁面中的地址偏移量，大小不固定，插入的記錄越多，這個部分佔用的空間越多。
複製程式碼

3. 每個記錄的頭資訊中都有一個next_record屬性，從而使頁中的所有記錄串聯成一個單向連結串列。
4. InnoDB會為把頁中的記錄劃分為若干個組，每個組的最後一個記錄的地址偏移量作為一個槽，存放在Page Directory中，所以在一個頁中根據主鍵查詢記錄是非常快的，分為兩步：
   • 通過二分法確定該記錄所在的槽。
   • 通過記錄的next_record屬性組成的連結串列遍歷查詢該槽中的各個記錄。
5. 每個資料頁的File Header部分都有上一個和下一個頁的編號，所以所有的資料頁會組成一個雙連結串列。
6. 為保證從記憶體中同步到磁碟的頁的完整性，在頁的首部和尾部都會儲存頁中資料的校驗和和LSN值，如果首部和尾部的校驗和和LSN值校驗不成功的話，就說明同步過程出現了問題。

最後

​ 本文的大部分內容都是參考並使用的原文中的內容，只是在中間加入了一些自己的理解，並希望把它更清楚的表達出來，大家也可以去看看原文：

​ InnoDB資料頁結構

​ 如果有地方理解的不對，還望指教。