前言

MySQL中的Undo Log、Redo Log 和Binlog是保障數據庫事務安全、數據一致性和高可用性的核心組件。它們分工明確，協同工作，但各自有不同的設計目標和實現機制。

Undo Log：保障事務原子性與 MVCC 的基石

作用

Undo Log主要用于事務回滾以及實現多版本并發控制（MVCC）。在事務執行過程中，當進行諸如INSERT、UPDATE、DELETE等寫操作時，數據庫會將修改前的數據副本記錄在Undo Log 中。這樣一來，如果事務執行過程中出現異常或者用戶主動執行ROLLBACK操作，數據庫可以依據Undo Log中的記錄，將數據恢復到事務開始前的狀態，從而保證了事務的原子性，即事務中的所有操作要么全部成功執行，要么全部不執行。

同時，在MVCC場景下，當一個事務對數據進行修改時，其他事務在讀取數據時，若讀取的行被鎖定，就可以從Undo Log中獲取該行數據在之前版本的狀態，實現非阻塞讀，提升數據庫的并發性能。

工作機制

根據操作類型，Undo Log可分為Insert Undo Log和Update Undo Log：

• Insert Undo Log用于INSERT操作的回滾，它主要記錄新插入記錄的主鍵信息，回滾時只需依據該主鍵刪除對應的記錄即可。
• Update Undo Log則用于UPDATE和DELETE操作的回滾，它會記錄被修改記錄的舊值，即修改前的完整數據行。在回滾時，使用舊值覆蓋當前值，以還原數據。

Undo Log存儲在InnoDB的Undo Tablespace中，其管理通過Rollback Segment（回滾段）來實現。每個Rollback Segment包含多個Undo Log Slot，用于存儲Undo Log記錄。

• 事務啟動時，會以輪詢的方式從Rollback Segment中分配空閑的Slot。
• 事務提交后，Slot并不會立即釋放，對于INSERT生成的TRX_UNDO_INSERT類型日志，事務提交后可立即釋放；而對于UPDATE/DELETE生成的TRX_UNDO_UPDATE類型日志，由于MVCC可能仍需訪問其歷史版本，所以需保留至所有快照讀不再引用，之后這些Slot中的Undo Log會被加入History List，由后臺Purge線程異步清理。
• 當事務回滾時，InnoDB會按照相反順序處理Undo Log記錄。對于Update Undo Log，執行更新操作，用舊值覆蓋當前值，從而完成數據的回滾。在快照讀時，InnoDB通過ReadView，依據隔離級別和事務ID，從Undo Log中讀取歷史版本數據，而非最新數據。Purge線程則負責在Undo Log記錄不再被任何事務的ReadView引用時，對其進行清理，回收空間。

Redo Log：確保事務持久性的關鍵

作用

Redo Log主要用于確保事務的持久性。當事務提交時，MySQL并不會立刻將所有修改的數據刷新到磁盤，因為磁盤I/O操作相對較慢，這樣會嚴重影響性能。而是先將修改內容記錄到 Redo Log中，之后再異步地將數據寫入磁盤。即使在數據庫發生崩潰、斷電等故障時，只要Redo Log 存在，系統在重啟后就可以依據Redo Log中的記錄，重新應用已提交事務的修改，保證已提交事務的數據不會丟失，從而實現事務的持久性。

工作機制

InnoDB采用Write-Ahead Logging（WAL）機制，即先寫日志，再寫磁盤。每次事務提交時，InnoDB會先將Redo Log寫入磁盤，而后再逐步將實際修改的數據寫入磁盤。在執行INSERT、UPDATE或DELETE操作時，數據庫會首先將修改記錄寫入Redo Log緩存。當事務提交時，系統會將Redo Log緩存中的內容刷入磁盤上的Redo Log文件。

Redo Log文件通常以循環的方式使用，當一個Redo Log文件寫滿后，會切換到下一個文件繼續寫入。InnoDB存儲引擎中，Redo Log的寫入操作是順序的，這相較于隨機寫磁盤，大大提高了寫入性能。在系統運行過程中，InnoDB會定期將Redo Log中的修改應用到數據頁，并將臟頁（即被修改但還未寫入磁盤的數據頁）刷新到磁盤。

當數據庫崩潰后重啟，MySQL會進入恢復階段。首先，進行Redo前滾階段，通過Redo Log 恢復已提交事務的數據頁；然后，掃描未提交事務的Undo日志，并按日志序列號（LSN）逆序執行補償操作，例如將INSERT操作補償為DELETE操作，UPDATE操作還原為修改前的狀態，從而確保數據庫的數據一致性。

Binlog：數據備份、恢復與復制的利器

作用

Binlog（二進制日志）主要有兩個重要作用。其一，用于數據庫的點時間恢復。通過記錄數據庫執行的所有寫操作，在需要時可以根據Binlog中的記錄，將數據庫恢復到指定時間點的狀態。其二，在主從復制架構中，Binlog起著關鍵作用。主庫將自身執行的寫操作記錄到Binlog中，從庫通過讀取主庫的Binlog，并在本地重放這些操作，從而實現與主庫的數據同步，保證主從庫數據的一致性。

工作機制

Binlog記錄的并非所有SQL語句，而是包含了已執行的SQL 語句（增、刪、改）的反向信息。例如，DELETE操作在Binlog中對應的是反向插入操作；UPDATE操作對應的是更新前后的版本信息；INSERT操作對應的是DELETE和INSERT操作。通過使用 mysqlbinlog工具解析Binlog，可以清晰地看到這些記錄。

當一個事務提交時，該事務中的每一條SQL 語句（一個事務可能對應多條SQL語句）都會以特定格式記錄在Binlog中。與Redo Log不同的是，Redo Log在事務開始后就逐步寫入磁盤，而Binlog是在事務提交時一次性寫入。Binlog的默認保留時間由expire_logs_days 參數設置，超過該時間的非活動日志文件會被自動刪除。

在主從復制過程中，主庫會將Binlog發送給從庫，從庫接收后，按照Binlog中的記錄順序，在本地依次執行相應的SQL操作，從而使從庫的數據與主庫保持一致。這種方式使得MySQL的主從復制架構能夠高效地實現數據的同步與備份，為數據的高可用性和災難恢復提供了有力支持。

關聯與協同工作

事務處理過程中的協同

當一個事務開始執行，Undo Log率先發揮作用，以UPDATE操作為例：

• 在對數據進行修改前，數據庫會將原始數據記錄到Undo Log中，為事務回滾提供依據，保障事務的原子性。同時Redo Log也開始記錄事務執行過程中對數據的修改操作，將其寫入 Redo Log` 緩存。
• 隨著事務推進，每一個寫操作產生的變化，不僅記錄在Redo Log緩存中，還會在Binlog中有所體現。Binlog在事務提交時，將事務涉及的SQL語句（增、刪、改）以特定格式記錄下來。當事務提交時，InnoDB會先將Redo Log緩存中的內容刷入磁盤上的Redo Log文件，確保已提交事務的修改不會因系統崩潰丟失，實現事務持久性；
• 隨后，Binlog也將事務記錄寫入文件，完成事務在二進制日志層面的記錄。而Undo Log中的記錄在事務提交后，對于INSERT類型日志可能會立即釋放相關資源，對于UPDATE/DELETE 類型日志，因MVCC需求會保留一段時間，直至不再被引用后由Purge線程清理。
• 在并發事務場景下，Undo Log實現的MVCC機制，使得讀取操作可以從Undo Log獲取數據歷史版本，避免對正在修改的數據加鎖，提升并發性能。與此同時，Redo Log持續記錄事務修改，Binlog也記錄著事務的寫操作，三者協同保證并發事務處理的正確性和高效性。

流程圖

故障恢復時的協作

當MySQL 數據庫遭遇崩潰、斷電等故障后重啟，Redo Log和Undo Log會緊密配合完成數據恢復工作。

• 首先，數據庫進入Redo前滾階段，通過Redo Log恢復已提交事務的數據頁，將數據庫狀態恢復到故障發生前已提交事務修改后的狀態。
• 接著，數據庫會掃描未提交事務的Undo日志，并按日志序列號（LSN）逆序執行補償操作。例如，將未提交事務中的INSERT操作補償為DELETE操作，UPDATE操作還原為修改前的狀態，以此確保數據庫的數據一致性。在這一過程中，Redo Log和Undo Log相互配合，Redo Log恢復已提交事務，Undo Log回滾未提交事務，二者共同保證數據庫在故障恢復后數據的完整性和一致性。

而Binlog在故障恢復中，主要用于基于時間點的恢復。如果數據庫因誤操作等原因需要恢復到某個特定時間點的狀態，可以通過解析Binlog，獲取從數據庫備份時間點到指定時間點之間的所有寫操作記錄，在恢復的數據庫實例上重放這些操作，從而將數據庫恢復到指定時間點的狀態。

主從復制中的配合

在MySQL主從復制架構中，Binlog是主從庫數據同步的核心。主庫在執行寫操作時，將這些操作記錄到Binlog中，從庫通過I/O線程連接主庫，獲取主庫的Binlog日志，并將其保存在從庫的中繼日志（Relay Log）中。

從庫的SQL線程讀取中繼日志中的內容，并在本地依次執行相應的SQL操作，實現與主庫的數據同步。在這一過程中，Redo Log和Undo Log同樣發揮著重要作用。從庫執行中繼日志中的 SQL操作時，如同在本地執行事務，Redo Log記錄著這些操作對數據的修改，保障從庫事務的持久性；Undo Log則用于處理可能的事務回滾，確保從庫數據的一致性。

例如，當從庫執行一個UPDATE操作時，Redo Log記錄該操作的修改，Undo Log記錄修改前的數據版本，若事務執行過程中出現異常，可通過Undo Log回滾事務；而Binlog則作為主從庫數據同步的橋梁，源源不斷地將主庫的寫操作傳遞給從庫。

總結

理解這三大日志之間的協同關系，有助于數據庫管理員更好地進行數據庫管理、性能優化和故障排查，也能讓開發人員在設計和開發數據庫應用時，充分利用數據庫特性，構建出更加穩定、可靠、高效的應用系統。