InnoDB 隔離等級對 MySQL 效能的深度影響分析

四大隔離等級效能特性

SERIALIZABLE

最強隔離，鎖定所有讀取，鎖管理開銷極大，並發極低，僅極特殊場景使用。

REPEATABLE READ（預設）

• 首次讀建立快照，後續讀同版本
• 代價：需從事務開始維護所有版本，undo log 膨脹
• 熱點列頻繁更新時，版本鏈極長，讀寫效能雙雙下降
• MySQL 5.6 版本控制導致嚴重爭用

實測：長事務 + 全表掃描對寫入吞吐量影響

Sysbench 64 執行緒、8000 萬筆資料、內存資料集：

sysbench --num-threads=64 --oltp-table-size=80000000
  --test=/usr/share/doc/sysbench/tests/db/update_index.lua run

寫入吞吐量在長事務開啟期間大幅下降並持續走低，即使查詢結束後仍未恢復。

測試用查詢組合

select avg(length(c)) from sbtest1;
begin;
select avg(length(c)) from sbtest1;
select sleep(300);
commit;

此模式同樣影響 mysqldump --single-transaction 與 mydumper 邏輯備份，大數據集下恢復時間過長、寫入頻繁環境不可用。

READ COMMITTED

• 每個語句讀取當前最新提交版本
• 減少版本維護，無長語句時效能優於 RR
• 長查詢（報表）仍有嚴重效能影響

READ UNCOMMITTED

• 讀取未提交資料（髒讀）
• 理論上可更早清理版本，但實作上受限於 bug/複雜度，長查詢仍產生版本
• 唯一優勢：不檢查舊版本，直接讀最新行，undo log 在磁盤時 IO 顯著降低
• 掃描大表 select avg(k) from sbtest1 時，RU 約 1 分鐘完成，RC 可能跑不完（插入速度 > 掃描速度）

建議策略

• 預設使用 READ COMMITTED
• 應用層確需可重複讀時，在事務層級升級為 REPEATABLE READ
• 正確使用隔離等級可獲得最佳效能

結語

InnoDB 歷史版本管理仍有大量優化空間，期待未來版本改善。