InnoDB Insert Buffer (Change Buffer) 核心機制深度解析

InnoDB Insert Buffer (Change Buffer) 核心機制深度解析

Change Buffer（舊稱 Insert Buffer）是 InnoDB 針對非唯一輔助索引的寫入優化子系統。本文從定義、原理、內部結構、合併調度、缺點、監控六個維度進行系統性剖析。

一、什麼是 Change Buffer

• 物理形態：一棵全局 B+ 樹，存放於共享表空間 ibdata1
• 非緩存頁，而是持久化物理頁
• 緩存操作：INSERT、UPDATE、DELETE、PURGE（非唯一輔助索引）
• MySQL 4.1 前：每表一棵；4.1+：全局單棵

二、為什麼只針對非唯一輔助索引

1. 聚簇索引通常按主鍵遞增寫入 → 順序 I/O，無隨機讀寫壓力
2. 唯一索引寫入前必須讀頁檢查唯一性 → 產生隨機讀，緩衝失去意義

三、核心原理：隨機轉順序

當目標索引頁不在 Buffer Pool：

1. 構造 search_key = space_id(4B) + marker(1B) + page_offset(4B)
2. 插入 Change Buffer B+ 樹葉子節點，記錄格式：space | marker | offset | metadata | secondary_index_record
3. 配合 Insert Buffer Bitmap 頁記錄各索引頁剩餘空間，保證合併可行

四、Master Thread 合併調度機制

• 合併頁數 = 系統 I/O 能力 5%
• 讀取採用 Async I/O，寫入合併後髒頁標記 flush

五、內部實現細節

• 非葉節點存 9 字節 search_key
• 葉節點存完整輔助索引記錄
• 全局單棵 B+ 樹 → .ibd 单獨複製恢復會導致輔助索引不全，需 REPAIR TABLE 重建

六、三大缺點與風險

1. 崩潰恢復變長：大量未合併變更需啟動時回放
2. 佔用 Buffer Pool：預設上限 50%（innodb_change_buffer_max_size），寫密集場景擠佔熱數據緩存
3. 不可精細控制：無法按表/索引粒度啟停，SSD 時代收益遞減

七、監控指標解讀

SHOW ENGINE INNODB STATUS \G
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 
      41 inserts, 41 merged recs, 499 merges
Hash table size 3984403, node heap has 967 buffer(s)
14.66 hash searches/s, 64.65 non-hash searches/s

• size = seg size - (1 + free list len)（含頭頁）
• seg size：Change Buffer 總頁數（預設 2 頁 = 32KB）
• merges：總合併次數
• merged recs：合併記錄數
• discarded：被丟棄的合併（頁已在內存直接修改）

八、參數控制

innodb_change_buffering = inserts|none|all|changes|purges  -- 預設 all
innodb_change_buffer_max_size = 50  -- 佔 Buffer Pool 最大百分比

九、官方文檔參考

• InnoDB Standard Monitor
• InnoDB Insert Buffering
• Percona: Little-known facts about Insert Buffer

總結

Change Buffer 是機械硬碟時代為緩解隨機 I/O 而生的經典設計。SSD 普及後，其邊際收益下降，但對寫入密集、非唯一索引多的 OLTP 仍有價值。建議：保持開啟，監控 Ibuf 指標，若合併頻繁導致被動合併延遲明顯，考慮調低 max_size 或針對性關閉特定表索引的 change buffering（MySQL 8.0+ 支援表級控制）。