iT邦幫忙

2021 iThome 鐵人賽

DAY 14
0
自我挑戰組

那些Mysql我不知道的事系列 第 14

InnoDB的表格空間-Part2(各類型頁面詳細情況)

今天來進一步探討更細節的幾個問題
像是XDES Entry結構到底儲存在表格空間的那邊?
直屬於表格空間的鏈結串列基節點儲存在表格空間那邊?
每個段對應的INODE Entry結構儲存在表格空間那邊?

為此我們需要更進一步了解前面提到的一些分組前面的固定頁面

  1. FSP_HDR類型。
    我們知道這頁用來登記整個表格空間的一些整體屬性及本組所有區的屬性。
    其實XDES Entry結構就是儲存在這裡。
    這頁包含了

    • File Header:檔案標頭(38位元組),頁的一些通用資訊
    • File Space Header:表格空間頭部(112位元組),表格空間的一些整體屬性資訊
    • XDES Entry:區描述資訊(10240位元組),儲存本組256個區對應的屬性資訊
    • Empty Space:尚未使用空間(5986位元組),用於頁結構的填充,沒什麼實際意義
    • File Trailer:檔案結尾(8位元組),驗證頁是否完整

    這裡File Header、File Trailer不特別強調,Empty Space這也不用管它
    我們看兩個重要的屬性就好
    第一個File Space Header

    • Space ID(4位元組):表格空間ID
    • Not Used(4位元組):未被使用,可忽略
    • Size(4位元組):當前表格空間擁有的頁面數
    • Free Limit(4位元組):尚未被初始化的最小頁號,大於或等於這個頁號對應的XDES Entry結構都沒有被加入FREE鏈結串列,也就是說一開始只分配一部分空閒區到FREE鏈結串列,等空閒鏈結串列中對應的XDES Entry結構不夠的時候,再把其加入。
    • Space Flags(4位元組):表格空間的一些佔用儲存空間比較小的屬性
    • FRAG_N_USED(4位元組):FREE_FRAG鏈結串列中已使用的頁面數量
    • List Base Node for FREE List(16位元組):FREE鏈結串列基節點
    • List Base Node for FREE_FRAG List(16位元組):FREE_FRAG鏈結串列基節點
    • List Base Node for FULL_FRAG List(16位元組):FULL_FRAG鏈結串列基節點
    • Next Unused Segment ID(8位元組):當前表格空間中下一個未使用的Segment ID,這樣新增段的時候就不需要歷遍整個空間中所有的段來知道下一個段ID是多少。
    • List Base Node for SEG_INODES_FULL List(16位元組):SEG_INODES_FULL鏈結串列的基節點,下方會再說明
    • List Base Node for SEG_INODES_FREE List(16位元組):SEG_INODES_FREE鏈結串列的基節點,下方會再說明

    第二個XDES Entry
    再來XDES Entry的部分,由於一個XDES Entry結構的大小是40位元組,由於一個頁面的大小有限,只能存放一定數量的XDES Entry結構,所以才把256個區畫成1組,每組的第一頁存放256個XDES Entry結構。

    所以我們前面的問題都有了答案
    像是XDES Entry結構到底儲存在表格空間的那邊?
    直屬於表格空間的鏈結串列基節點儲存在表格空間那邊?
    每個段對應的INODE Entry結構儲存在表格空間那邊?
    都是存在每組最開始的第一頁

  2. XDES類型
    大家還記得其餘各組最開始二頁的類型是固定的,第一頁是XDES頁,用來登記本組256個區的屬性。基本上它的內容跟FSP_HDR幾乎一樣,差別只在於XDES沒有File Space Header(紀錄表格空間的一些整體屬性資訊)。

  3. IBUF_BITMAP類型
    所有組別的第二頁都是IBUF_BITMAP頁,用來儲存關於Change Buffer的一些資料。
    我們在表中插入一筆紀錄,本質上是向每個索引對應的B+樹插入紀錄。該紀錄先插入聚簇索引頁面,然後再插入每個二級索引頁面。這些頁面在表格空間中隨機分佈(雖然有雙向鏈結串列串在一起,但物理記憶體上是不連續的,所以磁碟需要重新定位),也產生大量的隨機I/O,嚴重影響性能。所以引入了Change Buffer結構(本質上也是表格空間中的一顆B+樹,它的根節點儲存在系統表格空間中)。在修改非唯一二級索引頁面時,如果該頁尚未被載入到記憶體中(仍在磁碟),那麼該修改先暫時快取到Change Buffer,等其需要載入到記憶體,才將修改合併到對應頁面。(以前只會快取Insert操作,所以Change Buffer以前被稱為Insert Buffer[IBUF],但現在Update跟Delete也會快取)

  4. INODE類型
    第一組的第三頁是INODE,顧名思義就是為了儲存INODE Entry結構而存在的,也就是說跟第一頁有些類似。內容如下:
    這頁包含了

    • File Header:檔案標頭(38位元組),頁的一些通用資訊
    • List Node for INODE Page List:表格空間頭部(12位元組),儲存上一個INODE page和下一個INODE頁面指標
    • INODE Entry:段描述資訊(16320位元組),具體的INODE Entry結構
    • Empty Space:尚未使用空間(6位元組),用於頁結構的填充,沒什麼實際意義
    • File Trailer:檔案結尾(8位元組),驗證頁是否完整
      我們看兩個不熟悉的屬性就好
      第一個INODE Entry
      我們已經知道的結構就是對應段內的零散頁面的位址及附屬於該段的FREE、NOT_FULL和FULL鏈結串列的基節點。每個INODE Entry結構佔用192位元組,一個頁面可以儲存16320/192=85個這樣的結構。
      第二個List Node for INODE Page List
      當一個表格空間段的數量超過85個就會不夠,需要額外的INODE頁來儲存,因此為了方便管理這些INODE頁,又將其串成兩個鏈結串列。
      SEG_INODES_FULL List(16位元組):SEG_INODES_FULL鏈結串列的基節點
      SEG_INODES_FULL List(16位元組):SEG_INODES_FULL鏈結串列的基節點
      這前面大家都有看到,它們的基節點的位置都是固定的,從而輕鬆存取。而指標的部分就存在這。

上一篇
InnoDB的表格空間-Part1(區、段、區的分類、段的結構)
下一篇
InnoDB的表格空間-Part3(系統表格空間)
系列文
那些Mysql我不知道的事30

尚未有邦友留言

立即登入留言