前言

在 MySQL 數(shù)據(jù)庫(kù)中，日志系統(tǒng)是保障數(shù)據(jù)一致性、支持事務(wù)和故障恢復(fù)的核心組件。其中，redo log（重做日志）、undo log（回滾日志）和 binlog（二進(jìn)制日志）被稱為"三大日志"，它們分工協(xié)作，共同維護(hù)著數(shù)據(jù)庫(kù)的可靠性和可用性。本文將深入解析這三種日志的工作原理、應(yīng)用場(chǎng)景及它們之間的協(xié)同機(jī)制。

1. redo log（重做日志）：保障數(shù)據(jù)持久性

1.1 什么是 redo log？

redo log 是 InnoDB 存儲(chǔ)引擎特有的物理日志，用于記錄數(shù)據(jù)頁(yè)的物理修改操作。它的核心作用是保證事務(wù)的持久性（ACID 中的 D），防止 MySQL 意外崩潰后丟失已提交的數(shù)據(jù)。

1.2 工作原理：Write-Ahead Logging (WAL)

redo log 采用了預(yù)寫(xiě)日志機(jī)制，即當(dāng)事務(wù)執(zhí)行數(shù)據(jù)修改時(shí)：

1. 先將修改操作記錄到內(nèi)存中的 redo log buffer
2. 再異步或同步地將 redo log 寫(xiě)入磁盤(pán)
3. 最后在合適的時(shí)機(jī)將內(nèi)存中的數(shù)據(jù)頁(yè)（Buffer Pool）刷寫(xiě)到磁盤(pán)

這種機(jī)制確保了即使數(shù)據(jù)還未寫(xiě)入磁盤(pán)，只要 redo log 已持久化，MySQL 重啟后就能通過(guò) redo log 恢復(fù)這些修改，從而保證已提交事務(wù)的數(shù)據(jù)不會(huì)丟失。

1.3 關(guān)鍵特性

• 循環(huán)寫(xiě)機(jī)制：redo log 文件大小固定，寫(xiě)滿后會(huì)覆蓋舊的日志記錄（已刷盤(pán)的數(shù)據(jù)對(duì)應(yīng)的日志可被覆蓋）
• 物理日志：記錄的是"某數(shù)據(jù)頁(yè)的某個(gè)位置做了什么修改"，例如"表空間 X 中頁(yè) Y 的偏移量 Z 寫(xiě)入了值 A"
• 高性能：順序?qū)懭氪疟P(pán)，避免了隨機(jī) I/O 的性能開(kāi)銷

1.4 刷盤(pán)策略配置

redo log 的刷盤(pán)策略由 innodb_flush_log_at_trx_commit 參數(shù)控制，有三種取值：

-- 查看當(dāng)前配置
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

• 1（默認(rèn)值，最安全）：事務(wù)提交時(shí)，立即將 redo log 從內(nèi)存寫(xiě)入磁盤(pán)并等待完成。即使 MySQL 或服務(wù)器崩潰，已提交的事務(wù)也不會(huì)丟失，但性能開(kāi)銷較大。

• 0（性能優(yōu)先）：事務(wù)提交時(shí)，僅將 redo log 寫(xiě)入內(nèi)存的 log buffer，不立即刷盤(pán)。每隔 1 秒由后臺(tái)線程批量刷盤(pán)?？赡軄G失最近 1 秒內(nèi)的已提交事務(wù)。

• 2（平衡策略）：事務(wù)提交時(shí)，將 redo log 寫(xiě)入操作系統(tǒng)緩存（OS cache），但不立即刷到物理磁盤(pán)。操作系統(tǒng)會(huì)定期刷盤(pán)。比 0 更安全（僅在 OS 崩潰時(shí)可能丟失數(shù)據(jù)）。

2. undo log（回滾日志）：保障事務(wù)原子性

2.1 什么是 undo log？

undo log 是 InnoDB 存儲(chǔ)引擎的邏輯日志，用于記錄事務(wù)修改前的數(shù)據(jù)狀態(tài)。它的核心作用是保障事務(wù)的原子性（ACID 中的 A），支持事務(wù)回滾操作，同時(shí)也是實(shí)現(xiàn) MVCC（多版本并發(fā)控制）的基礎(chǔ)。

2.2 工作原理

當(dāng)事務(wù)執(zhí)行修改操作時(shí)：

1. InnoDB 會(huì)先記錄數(shù)據(jù)修改前的狀態(tài)到 undo log
2. 如果事務(wù)執(zhí)行失敗或調(diào)用 ROLLBACK，InnoDB 會(huì)利用 undo log 還原數(shù)據(jù)到修改前的狀態(tài)
3. 在 MVCC 機(jī)制中，其他事務(wù)可以通過(guò) undo log 訪問(wèn)數(shù)據(jù)的歷史版本，實(shí)現(xiàn)"讀不加鎖"

例如，當(dāng)執(zhí)行 UPDATE t SET name = 'B' WHERE id = 1 時(shí)，undo log 會(huì)記錄"將 id=1 的 name 改回 ‘A’"（假設(shè)原來(lái)的值是 ‘A’）。

2.3 關(guān)鍵特性

• 邏輯日志：記錄的是操作的逆過(guò)程（邏輯指令），而非物理地址
• 多版本支持：每個(gè)事務(wù)看到的數(shù)據(jù)版本由 undo log 維護(hù)
• 可回收性：事務(wù)提交后，undo log 不會(huì)立即刪除，而是被標(biāo)記為可回收，由后臺(tái) purge 線程定期清理

2.4 存儲(chǔ)與刷盤(pán)

undo log 存儲(chǔ)在 InnoDB 的 undo 表空間中，本質(zhì)上是一種特殊的數(shù)據(jù)頁(yè)。它的刷盤(pán)策略與普通數(shù)據(jù)頁(yè)一致：

• 先寫(xiě)入內(nèi)存中的 Buffer Pool
• 通過(guò) Checkpoint 機(jī)制異步批量刷盤(pán)
• 其自身的持久性由 redo log 保障（undo log 的修改會(huì)被記錄到 redo log 中）

3. binlog（二進(jìn)制日志）：支持復(fù)制與恢復(fù)

3.1 什么是 binlog？

binlog 是 MySQL 服務(wù)器層的邏輯日志，記錄了所有 DDL（數(shù)據(jù)定義語(yǔ)言）和 DML（數(shù)據(jù)操縱語(yǔ)言）操作。它不依賴于特定的存儲(chǔ)引擎，所有引擎都可以使用。

3.2 主要作用

• 主從復(fù)制：主庫(kù)的 binlog 發(fā)送到從庫(kù)，從庫(kù)重放日志以保持?jǐn)?shù)據(jù)同步
• 時(shí)間點(diǎn)恢復(fù)（PITR）：結(jié)合全量備份，通過(guò)重放 binlog 可以將數(shù)據(jù)庫(kù)恢復(fù)到指定時(shí)間點(diǎn)
• 審計(jì)：記錄所有數(shù)據(jù)修改操作，便于追溯

3.3 工作原理

當(dāng)執(zhí)行數(shù)據(jù)修改操作時(shí)：

1. 操作會(huì)被記錄到 binlog 緩存中
2. 事務(wù)提交時(shí)，binlog 會(huì)被寫(xiě)入磁盤(pán)
3. binlog 以事件形式記錄，包含操作類型、數(shù)據(jù)變更、時(shí)間戳等信息

3.4 日志格式

binlog 有三種格式，通過(guò) binlog_format 參數(shù)配置：

-- 查看當(dāng)前格式
SHOW VARIABLES LIKE 'binlog_format';

• STATEMENT：記錄執(zhí)行的 SQL 語(yǔ)句。日志體積小，但可能存在主從數(shù)據(jù)不一致的風(fēng)險(xiǎn)（如使用 NOW()、RAND() 等函數(shù)）。

• ROW：記錄數(shù)據(jù)行的修改細(xì)節(jié)（如"將 id=1 的 name 從 ‘A’ 改為 ‘B’"）。主從一致性最好，但日志體積較大。

• MIXED：默認(rèn)使用 STATEMENT 格式，特殊場(chǎng)景自動(dòng)切換為 ROW 格式，平衡了日志體積和一致性。

3.5 刷盤(pán)策略

binlog 的刷盤(pán)策略由 sync_binlog 參數(shù)控制：

-- 查看當(dāng)前配置
SHOW VARIABLES LIKE 'sync_binlog';

• 1（最安全）：每次事務(wù)提交時(shí)，立即將 binlog 從內(nèi)存緩存刷到物理磁盤(pán)。保證 binlog 不丟失，但性能開(kāi)銷大。

• 0（性能優(yōu)先）：事務(wù)提交時(shí)，僅將 binlog 寫(xiě)入操作系統(tǒng)緩存（OS cache），不立即刷盤(pán)。由操作系統(tǒng)決定何時(shí)刷盤(pán)，可能丟失未刷盤(pán)的 binlog。

• N（N>1，平衡策略）：每累積 N 個(gè)事務(wù)提交后，觸發(fā)一次 binlog 刷盤(pán)。減少刷盤(pán)次數(shù)，最多可能丟失 N-1 個(gè)事務(wù)的 binlog。

4. 三大日志的協(xié)同工作機(jī)制

在一個(gè)完整的事務(wù)處理過(guò)程中，三種日志會(huì)協(xié)同工作，確保數(shù)據(jù)的一致性和可靠性：

1. 事務(wù)開(kāi)始：InnoDB 為事務(wù)分配事務(wù) ID
2. 執(zhí)行修改：
   • 記錄數(shù)據(jù)修改前的狀態(tài)到 undo log
   • 修改內(nèi)存中的數(shù)據(jù)頁(yè)（Buffer Pool）
   • 記錄數(shù)據(jù)頁(yè)的修改到 redo log buffer
3. 事務(wù)提交：
   • 執(zhí)行兩階段提交（2PC）：
     a. 階段一：將 redo log 標(biāo)記為"prepare"狀態(tài)并刷盤(pán)
     b. 階段二：寫(xiě)入 binlog 并刷盤(pán)
     c. 階段三：將 redo log 標(biāo)記為"commit"狀態(tài)并刷盤(pán)
   • 釋放鎖資源
4. 后臺(tái)操作：
   • 定期將 Buffer Pool 中的數(shù)據(jù)頁(yè)刷寫(xiě)到磁盤(pán)
   • 事務(wù)提交后，undo log 被標(biāo)記為可回收，等待 purge 線程清理

這種協(xié)同機(jī)制確保了：

• 即使 MySQL 崩潰，redo log 保證已提交事務(wù)的數(shù)據(jù)不丟失
• 若事務(wù)失敗，undo log 保證可以回滾到修改前的狀態(tài)
• binlog 保證了主從復(fù)制的數(shù)據(jù)一致性和時(shí)間點(diǎn)恢復(fù)能力

5. 三大日志的核心區(qū)別

6. 總結(jié)

MySQL 的三大日志各有側(cè)重又協(xié)同工作，共同構(gòu)建了數(shù)據(jù)庫(kù)的事務(wù)安全和可靠性體系：

• redo log 確保了已提交事務(wù)的數(shù)據(jù)不會(huì)因崩潰而丟失，是數(shù)據(jù)庫(kù)"crash-safe"的基礎(chǔ)
• undo log 提供了事務(wù)回滾能力，并支撐了 MVCC 機(jī)制，實(shí)現(xiàn)了高并發(fā)下的讀一致性
• binlog 則是主從復(fù)制和時(shí)間點(diǎn)恢復(fù)的核心，支撐了 MySQL 的分布式架構(gòu)

理解這三種日志的工作原理和協(xié)同機(jī)制，對(duì)于數(shù)據(jù)庫(kù)性能優(yōu)化、故障排查和架構(gòu)設(shè)計(jì)都具有重要意義。在實(shí)際應(yīng)用中，應(yīng)根據(jù)業(yè)務(wù)需求合理配置日志參數(shù)，在數(shù)據(jù)安全性和性能之間找到最佳平衡點(diǎn)。

到此這篇關(guān)于MySQL三大日志之redo log、undo log、binlog的文章就介紹到這了,更多相關(guān)MySQL日志redo log、undo log、binlog內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論