MySQL 事務深度解析：ACID 特性、隔離級別、MVCC 與 Redo/Undo Log 機制

為什麼需要事務？

經典轉帳場景：A 轉 500 元給 B，需執行「檢查餘額 → A 扣款 → B 入帳」。若扣款後系統崩潰，A 損失 500 而 B 未收到款。事務確保這組操作要麼全成功、要麼全失敗。

事務的 ACID 四大特性

四種隔離級別與並發異常

關鍵差異：

• 髒讀：讀到未提交的資料
• 不可重複讀：同一事務多次讀取同一行，結果不同（被修改）
• 幻讀：同一事務多次範圍查詢，行數不同（被插入/刪除）

MySQL InnoDB 的事務實作亮點

1. RR 級別實現了「近似串行化」效果

InnoDB 預設 RR，透過 MVCC（多版本並發控制） 解決不可重複讀，配合 間隙鎖 解決幻讀，兼顧並發效能與資料一致性。

2. Redo Log：保障持久性與一致性

• 事務開啟時，操作先寫入 InnoDB Log Buffer
• 提交前，日誌先行：Buffer 刷盤持久化
• 提交後，Buffer Pool 中的資料頁非同步刷盤
• 崩潰恢復：重啟時根據 Redo Log 將資料庫恢復到崩潰前狀態
• 順序 IO 寫入，效能高；所有事務共享一個循環寫入的 Redo Log 檔案組

3. Undo Log：保障原子性

• 記錄每次操作前的資料狀態
• 回滾時依據 Undo Log 還原，僅影響當前事務
• 配合 Redo Log 實現完整的崩潰恢復與回滾機制

簡化的事務執行流程

start transaction;
記錄 A=1 到 undo log;
update A = 3;
記錄 A=3 到 redo log;
記錄 B=2 到 undo log;
update B = 4;
記錄 B=4 到 redo log;
將 redo log 刷盤;
commit;

• 步驟 1-8 任意點崩潰 → 事務未提交，不影響磁碟資料
• 步驟 8-9 之間崩潰 → Redo Log 已持久化，恢復後可選擇回滾或繼續提交
• 步驟 9 後崩潰 → 依據 Redo Log 將記憶體資料刷回磁碟

分散式事務：兩階段提交 (2PC)

模型包含：應用程式 (AP)、資源管理器 (RM)、事務管理器 (TM)。

1. 準備階段：所有節點執行操作，回報 Ready
2. 提交階段：TM 通知所有節點 Commit 或 Rollback
3. 任一節點失敗 → 全域回滾，保證原子性

InnoDB 原生支援 XA 事務，亦可用訊息佇列實現最終一致性。

總結

事務是訂單、銀行等核心業務的基石。InnoDB 透過 MVCC、間隙鎖、Redo/Undo Log 精妙實現了高效能的 ACID 保證。理解其底層機制，有助於正確設計隔離級別、排查鎖爭用、優化長事務效能。

參考：《高效能 MySQL 第 3 版》、《MySQL 技術內幕：InnoDB 存儲引擎》