MySQL如何實現事務的四大特性（ACID）
MySQL的事務支持主要通過InnoDB存儲引擎實現，其底層機制結合日誌系統（Undo Log/Redo Log）、鎖機制和多版本併發控制（MVCC），具體實現如下：
1. 原子性（Atomicity）
定義：事務的所有操作要麼全部成功，要麼全部失敗回滾。
實現：
-
Undo Log（回滾日誌）：
- 在事務修改數據前，Undo Log會記錄數據修改前的狀態（舊版本數據）。
- 若事務需要回滾，InnoDB會根據Undo Log逆向執行操作，恢復數據到事務開始前的狀態。
-
物理實現：
- Undo Log存儲在Undo Tablespace中，按事務ID組織。
- 每條修改記錄（INSERT/UPDATE/DELETE）對應一條Undo Log。
2. 一致性（Consistency）
定義：事務執行後，數據庫從一個一致性狀態轉換到另一個一致性狀態。
實現：
- 應用層約束：通過外鍵、唯一索引、非空約束等保證數據完整性。
-
數據庫機制輔助：
- 原子性、隔離性、持久性：三者共同保障一致性。例如，事務回滾（原子性）可撤銷中間狀態，MVCC（隔離性）避免髒讀破壞一致性。
- Double Write Buffer：確保數據頁寫入的完整性，防止部分寫失敗導致數據損壞。
3. 隔離性（Isolation）
定義：併發事務之間互不干擾，防止髒讀、不可重複讀、幻讀等問題。
實現：
-
鎖機制：
- 行級鎖：InnoDB默認使用行鎖（Record Lock）和間隙鎖（Gap Lock）控制併發訪問。
- 意向鎖（Intention Lock）：快速判斷表中是否存在行級鎖，優化鎖衝突檢測。
-
MVCC（多版本併發控制）：
- Read View：事務開啓時生成一個Read View，記錄當前活躍事務ID列表。
- 版本鏈：每條記錄通過隱藏字段（
DB_TRX_ID、DB_ROLL_PTR）鏈接到Undo Log中的歷史版本。 - 可見性判斷：根據事務ID和Read View判斷數據版本是否可見，避免讀寫衝突。
不同隔離級別的實現差異：
| 隔離級別 | 實現機制 |
|----------------------|-----------------------------------------------------------------------------|
| 讀未提交（RU） | 直接讀取最新數據，無鎖和MVCC控制。 |
| 讀已提交（RC） | 每次查詢生成新Read View，解決髒讀。 |
| 可重複讀（RR） | 事務首次查詢生成Read View，後續複用，解決不可重複讀和幻讀（通過間隙鎖）。 |
| 串行化（SERIAL） | 強制所有操作加鎖，退化為悲觀併發控制。 |
4. 持久性（Durability）
定義：事務提交後，修改永久保存，即使系統崩潰也不丟失。
實現：
-
Redo Log（重做日誌）：
- Write-Ahead Logging（WAL）：事務提交前，先將所有修改寫入Redo Log（順序寫，高性能）。
-
物理實現：
- Redo Log文件（
ib_logfile0、ib_logfile1）循環寫入，記錄數據頁的物理修改（如頁號、偏移量）。 - 通過LSN（Log Sequence Number）標識日誌寫入位置，確保恢復時精準定位。
- Redo Log文件（
-
Checkpoint機制：
- 定期將髒頁（修改後的數據頁）刷新到磁盤，並更新Checkpoint LSN，減少恢復時需要重放的日誌量。
-
Double Write Buffer：
- 數據頁寫入磁盤前，先寫入Double Write Buffer，防止部分頁寫入（Partial Write）導致數據損壞。
關鍵組件協作流程示例
- 事務啓動：分配事務ID（
TRX_ID），生成Undo Log和Read View（MVCC）。 -
數據修改：
- 加行鎖（如X鎖），記錄Undo Log（舊數據版本）。
- 修改數據頁，生成Redo Log（新數據狀態）。
-
事務提交：
- 將Redo Log刷盤（
fsync），確保持久性。 - 釋放行鎖，清理Undo Log（僅當無其他事務依賴時）。
- 將Redo Log刷盤（
-
崩潰恢復：
- 通過Redo Log重放未刷盤的修改。
- 通過Undo Log回滾未提交的事務。
總結
- 原子性：依賴Undo Log實現回滾能力。
- 一致性：通過ACID三特性+應用約束共同保障。
- 隔離性：結合鎖（悲觀控制）和MVCC（樂觀控制）實現多粒度隔離。
- 持久性：通過Redo Log和WAL策略確保數據持久化。
InnoDB通過這些機制的協同工作，在保證高性能的同時，完整支持事務的ACID特性。
