前言

MySQL中的Undo Log、Redo Log 和Binlog是保障數(shù)據(jù)庫事務(wù)安全、數(shù)據(jù)一致性和高可用性的核心組件。它們分工明確，協(xié)同工作，但各自有不同的設(shè)計目標(biāo)和實現(xiàn)機制。

Undo Log：保障事務(wù)原子性與 MVCC 的基石

作用

Undo Log主要用于事務(wù)回滾以及實現(xiàn)多版本并發(fā)控制（MVCC）。在事務(wù)執(zhí)行過程中，當(dāng)進行諸如INSERT、UPDATE、DELETE等寫操作時，數(shù)據(jù)庫會將修改前的數(shù)據(jù)副本記錄在Undo Log 中。這樣一來，如果事務(wù)執(zhí)行過程中出現(xiàn)異?；蛘哂脩糁鲃訄?zhí)行ROLLBACK操作，數(shù)據(jù)庫可以依據(jù)Undo Log中的記錄，將數(shù)據(jù)恢復(fù)到事務(wù)開始前的狀態(tài)，從而保證了事務(wù)的原子性，即事務(wù)中的所有操作要么全部成功執(zhí)行，要么全部不執(zhí)行。

同時，在MVCC場景下，當(dāng)一個事務(wù)對數(shù)據(jù)進行修改時，其他事務(wù)在讀取數(shù)據(jù)時，若讀取的行被鎖定，就可以從Undo Log中獲取該行數(shù)據(jù)在之前版本的狀態(tài)，實現(xiàn)非阻塞讀，提升數(shù)據(jù)庫的并發(fā)性能。

工作機制

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

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

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

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

Redo Log：確保事務(wù)持久性的關(guān)鍵

作用

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

工作機制

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

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

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

Binlog：數(shù)據(jù)備份、恢復(fù)與復(fù)制的利器

作用

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

工作機制

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

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

在主從復(fù)制過程中，主庫會將Binlog發(fā)送給從庫，從庫接收后，按照Binlog中的記錄順序，在本地依次執(zhí)行相應(yīng)的SQL操作，從而使從庫的數(shù)據(jù)與主庫保持一致。這種方式使得MySQL的主從復(fù)制架構(gòu)能夠高效地實現(xiàn)數(shù)據(jù)的同步與備份，為數(shù)據(jù)的高可用性和災(zāi)難恢復(fù)提供了有力支持。

關(guān)聯(lián)與協(xié)同工作

事務(wù)處理過程中的協(xié)同

當(dāng)一個事務(wù)開始執(zhí)行，Undo Log率先發(fā)揮作用，以UPDATE操作為例：

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

流程圖

故障恢復(fù)時的協(xié)作

當(dāng)MySQL 數(shù)據(jù)庫遭遇崩潰、斷電等故障后重啟，Redo Log和Undo Log會緊密配合完成數(shù)據(jù)恢復(fù)工作。

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

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

主從復(fù)制中的配合

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

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

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

總結(jié)

理解這三大日志之間的協(xié)同關(guān)系，有助于數(shù)據(jù)庫管理員更好地進行數(shù)據(jù)庫管理、性能優(yōu)化和故障排查，也能讓開發(fā)人員在設(shè)計和開發(fā)數(shù)據(jù)庫應(yīng)用時，充分利用數(shù)據(jù)庫特性，構(gòu)建出更加穩(wěn)定、可靠、高效的應(yīng)用系統(tǒng)。