MySQL 事務回滾機制：DELETE 後 ROLLBACK 前資料去哪了？

現象描述

START TRANSACTION;
DELETE FROM t WHERE id = 1;
SELECT * FROM t;  -- 看不到資料
ROLLBACK;
SELECT * FROM t;  -- 資料又出現了

核心原理

• Undo Log（回滾日誌）：InnoDB 在執行 DELETE 時，不會立即從資料頁移除記錄，而是：
  1. 將舊版本記錄寫入 Undo Log（儲存於系統表空間或獨立 Undo 表空間）。
  2. 在資料頁上標記「刪除標記」，對當前事務可見性判斷為「已刪除」。
  3. 次要索引同步標記刪除。
• MVCC（多版本並發控制）：同一事務內後續 SELECT 依隔離級別（預設 REPEATABLE READ）讀取事務開始時的快照，或當前事務的修改，因此看不到被標記刪除的列。
• ROLLBACK：讀取 Undo Log 將資料頁恢復到事務開始前的狀態，移除刪除標記，資料再次可見。

資料實際位置

資料從未離開資料頁，只是被打上「刪除標記」並記錄舊版本於 Undo Log。緩衝池 中的資料頁已修改（髒頁），但未刷盤；Undo Log 同樣在緩衝池，定期由後台執行緒刷盤。

關鍵參數與監控

• innodb_undo_log_truncate、innodb_undo_tablespaces：控制 Undo 表空間獨立與截斷。
• SHOW ENGINE INNODB STATUS 中 History list length 反映未清理的 Undo 量。
• 長事務會導致 Undo Log 暴增，影響效能與磁碟空間。

總結

DELETE 到 ROLLBACK 期間，資料以「刪除標記 + Undo Log 舊版本」形式存在於記憶體緩衝池（並持久化至 Undo 表空間），並非另存一份完整副本。這正是事務原子性與隔離性的基石。