Facebook 實踐：InnoDB 邏輯預讀 + 批量異步 I/O 讓全表掃描提速 10-20 倍

Facebook 實踐：InnoDB 邏輯預讀 + 批量異步 I/O 讓全表掃描提速 10-20 倍

InnoDB 按主鍵順序全表掃描時，若主鍵頁碎片化嚴重 (如 PRIMARY KEY (user_id, object_id) 隨機插入導致頁分裂)，物理讀取變為**隨機 I/O**，HDD 上性能極差。Facebook 工程團隊在 InnoDB 內核實現 **Logical Read Ahead (LRA, 邏輯預讀)** 與 **批量提交異步 I/O**，在生產環境將 mysqldump、pt-online-schema-change 等全表掃描場景提速 **9-20 倍**。本文深度解析原理、實現、基準測試與開源補丁。

一、 痛點：碎片化表上的全表掃描 = 隨機 I/O

• InnoDB 掃描主鍵葉子頁順序由 B+Tree 邏輯順序決定。
• 頁分裂導致新頁分配在遠離邏輯鄰居的物理位置 (圖 1)。
• 掃描邏輯頁 #3 → 需讀物理頁 #5230 → 再讀 #4，**磁頭頻繁跳躍，吞吐從 100+ MB/s 跌至 10 MB/s 級**。
• 現有 Linear Read Ahead (線性預讀)：連續訪問 N 頁 (默認 56) 才觸發一次 Extent (64 頁/1MB) 讀取，**碎片表下幾乎永不觸發**，無效。

二、 邏輯預讀 核心設計

核心思想：利用 B+Tree 非葉子頁 (Branch Pages) 記錄的葉子頁指針，**按邏輯頁號順序批量預讀葉子頁**，再按主鍵順序返回行。

工作流程 (圖 2)

1. 讀取 Branch Pages：遍歷主鍵 B+Tree 非葉子層，收集所有葉子頁頁號。
2. 計算葉子頁總數：確定預讀範圍。
3. 按頁號順序批量預讀葉子頁：innodb_lra_size 控制每批頁數 (默認 512MB-4GB 內存預算)，innodb_lra_sleep 控制批次間休眠 (默認 50ms) 避免沖刷正常業務頁。
4. 按主鍵順序返回行**：從預讀入 Buffer Pool 的頁中提取記錄，邏輯順序不變。

會話級開關 (僅全表掃描啟用)

SET SESSION innodb_lra_size = 536870912;  -- 512MB
SET SESSION innodb_lra_sleep = 50000;     -- 50ms (微秒)
-- 執行全表掃描
SELECT * FROM huge_table INTO OUTFILE '/tmp/dump.txt';
-- 或 mysqldump 內部自動啟用

三、 批量異步 I/O 提交

問題：InnoDB 5.6+ 使用 Linux Native AIO (io_submit)，但**每次僅提交 1 頁 (16KB) 請求**，內核無法合併，IOPS 浪費。

修復：調用 io_submit 前**攒批多個連續頁請求** (如 64 頁 = 1MB) 一次提交。

效果 (RAID 1+0 HDD)：

• 單頁提交：~160 MB/s
• 64 頁批量提交：>1000 MB/s (**6.25x 吞吐提升**)

內核合併連續請求為大塊 I/O，極大提升磁盤順序讀效率。

四、 生產基準測試結果

**關鍵收穫**：LRA 解決「讀什麼」、批量 AIO 解決「怎麼讀」，兩者正交疊加，效果乘法級疊加。

五、 開源補丁獲取與應用

Facebook 已將增強提交至 MySQL 5.6 分支開源：

• Logical Read Ahead 實現：Diff 鏈接
• 批量異步 I/O 提交：Diff 鏈接
• mysqldump 集成 LRA 啟用：Diff 鏈接

適用於 MySQL 5.6 / Percona Server 5.6 / MariaDB 10.0+。MySQL 5.7/8.0 架構變化較大，需移植適配 (建議關注社區 innodb_parallel_read_threads 等新特性)。

六、 適用場景與局限

適用：

• mysqldump --single-transaction 邏輯備份
• SELECT ... INTO OUTFILE 導出
• pt-online-schema-change / gh-ost 拷貝階段
• ALTER TABLE ... ENGINE=InnoDB 重建表
• 大表全量掃描報表/分析 (會話級啟用)

不適用/無效**：

• 主鍵順序寫入、無碎片表 (已是順序讀，LRA 開銷無收益)。
• SSD/NVMe 隨機讀性能極強 (IOPS 無瓶頸)，收益邊際遞減。
• 高併發 OLTP 核心業務 (LRA 佔用 Buffer Pool、I/O 帶寬，需嚴格限流 innodb_lra_size/sleep)。

七、 總結與展望

Facebook 通過**邏輯層面順序化 (LRA)** + **系統調用層面批量化 (批量 AIO)**，以極小內核改動 (約 200 行) 解決了困擾 InnoDB 多年的「碎片表全表掃描慢」難題。**期望 Oracle 官方 / Percona / MariaDB 將其納入主線**，或在 8.0 中通過 innodb_parallel_read_threads、innodb_read_ahead_threshold 動態自適應等機制原生解決。在此之前，大表備份/變更慢的團隊可考慮打補丁編譯專用版本，或升級至 8.0 利用並行讀線程特性。