当前位置：首页 > news >正文

MySQL 三大日志：redo log、undo log、binlog 详解

news 2025/8/20 10:56:44

在 MySQL 数据库中，日志系统是保障数据一致性、支持事务和故障恢复的核心组件。其中，redo log（重做日志）、undo log（回滚日志）和 binlog（二进制日志）被称为"三大日志"，它们分工协作，共同维护着数据库的可靠性和可用性。本文将深入解析这三种日志的工作原理、应用场景及它们之间的协同机制。

1. redo log（重做日志）：保障数据持久性

1.1 什么是 redo log？

redo log 是 InnoDB 存储引擎特有的物理日志，用于记录数据页的物理修改操作。它的核心作用是保证事务的持久性（ACID 中的 D），防止 MySQL 意外崩溃后丢失已提交的数据。

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

redo log 采用了预写日志机制，即当事务执行数据修改时：

先将修改操作记录到内存中的 redo log buffer
再异步或同步地将 redo log 写入磁盘
最后在合适的时机将内存中的数据页（Buffer Pool）刷写到磁盘

这种机制确保了即使数据还未写入磁盘，只要 redo log 已持久化，MySQL 重启后就能通过 redo log 恢复这些修改，从而保证已提交事务的数据不会丢失。

1.3 关键特性

循环写机制：redo log 文件大小固定，写满后会覆盖旧的日志记录（已刷盘的数据对应的日志可被覆盖）
物理日志：记录的是"某数据页的某个位置做了什么修改"，例如"表空间 X 中页 Y 的偏移量 Z 写入了值 A"
高性能：顺序写入磁盘，避免了随机 I/O 的性能开销

1.4 刷盘策略配置

redo log 的刷盘策略由 innodb_flush_log_at_trx_commit 参数控制，有三种取值：

-- 查看当前配置
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

1（默认值，最安全）：事务提交时，立即将 redo log 从内存写入磁盘并等待完成。即使 MySQL 或服务器崩溃，已提交的事务也不会丢失，但性能开销较大。
0（性能优先）：事务提交时，仅将 redo log 写入内存的 log buffer，不立即刷盘。每隔 1 秒由后台线程批量刷盘。可能丢失最近 1 秒内的已提交事务。
2（平衡策略）：事务提交时，将 redo log 写入操作系统缓存（OS cache），但不立即刷到物理磁盘。操作系统会定期刷盘。比 0 更安全（仅在 OS 崩溃时可能丢失数据）。

2. undo log（回滚日志）：保障事务原子性

2.1 什么是 undo log？

undo log 是 InnoDB 存储引擎的逻辑日志，用于记录事务修改前的数据状态。它的核心作用是保障事务的原子性（ACID 中的 A），支持事务回滚操作，同时也是实现 MVCC（多版本并发控制）的基础。

2.2 工作原理

当事务执行修改操作时：

InnoDB 会先记录数据修改前的状态到 undo log
如果事务执行失败或调用 ROLLBACK，InnoDB 会利用 undo log 还原数据到修改前的状态
在 MVCC 机制中，其他事务可以通过 undo log 访问数据的历史版本，实现"读不加锁"

例如，当执行 UPDATE t SET name = 'B' WHERE id = 1 时，undo log 会记录"将 id=1 的 name 改回 ‘A’"（假设原来的值是 ‘A’）。

2.3 关键特性

逻辑日志：记录的是操作的逆过程（逻辑指令），而非物理地址
多版本支持：每个事务看到的数据版本由 undo log 维护
可回收性：事务提交后，undo log 不会立即删除，而是被标记为可回收，由后台 purge 线程定期清理

2.4 存储与刷盘

undo log 存储在 InnoDB 的 undo 表空间中，本质上是一种特殊的数据页。它的刷盘策略与普通数据页一致：

先写入内存中的 Buffer Pool
通过 Checkpoint 机制异步批量刷盘
其自身的持久性由 redo log 保障（undo log 的修改会被记录到 redo log 中）

3. binlog（二进制日志）：支持复制与恢复

3.1 什么是 binlog？

binlog 是 MySQL 服务器层的逻辑日志，记录了所有 DDL（数据定义语言）和 DML（数据操纵语言）操作。它不依赖于特定的存储引擎，所有引擎都可以使用。

3.2 主要作用

主从复制：主库的 binlog 发送到从库，从库重放日志以保持数据同步
时间点恢复（PITR）：结合全量备份，通过重放 binlog 可以将数据库恢复到指定时间点
审计：记录所有数据修改操作，便于追溯

3.3 工作原理

当执行数据修改操作时：

操作会被记录到 binlog 缓存中
事务提交时，binlog 会被写入磁盘
binlog 以事件形式记录，包含操作类型、数据变更、时间戳等信息

3.4 日志格式

binlog 有三种格式，通过 binlog_format 参数配置：

-- 查看当前格式
SHOW VARIABLES LIKE 'binlog_format';

STATEMENT：记录执行的 SQL 语句。日志体积小，但可能存在主从数据不一致的风险（如使用 NOW()、RAND() 等函数）。
ROW：记录数据行的修改细节（如"将 id=1 的 name 从 ‘A’ 改为 ‘B’"）。主从一致性最好，但日志体积较大。
MIXED：默认使用 STATEMENT 格式，特殊场景自动切换为 ROW 格式，平衡了日志体积和一致性。

3.5 刷盘策略

binlog 的刷盘策略由 sync_binlog 参数控制：

-- 查看当前配置
SHOW VARIABLES LIKE 'sync_binlog';

1（最安全）：每次事务提交时，立即将 binlog 从内存缓存刷到物理磁盘。保证 binlog 不丢失，但性能开销大。
0（性能优先）：事务提交时，仅将 binlog 写入操作系统缓存（OS cache），不立即刷盘。由操作系统决定何时刷盘，可能丢失未刷盘的 binlog。
N（N>1，平衡策略）：每累积 N 个事务提交后，触发一次 binlog 刷盘。减少刷盘次数，最多可能丢失 N-1 个事务的 binlog。

4. 三大日志的协同工作机制

在一个完整的事务处理过程中，三种日志会协同工作，确保数据的一致性和可靠性：

事务开始：InnoDB 为事务分配事务 ID
执行修改：
- 记录数据修改前的状态到 undo log
- 修改内存中的数据页（Buffer Pool）
- 记录数据页的修改到 redo log buffer
事务提交：
- 执行两阶段提交（2PC）：
  a. 阶段一：将 redo log 标记为"prepare"状态并刷盘
  b. 阶段二：写入 binlog 并刷盘
  c. 阶段三：将 redo log 标记为"commit"状态并刷盘
- 释放锁资源
后台操作：
- 定期将 Buffer Pool 中的数据页刷写到磁盘
- 事务提交后，undo log 被标记为可回收，等待 purge 线程清理

这种协同机制确保了：

即使 MySQL 崩溃，redo log 保证已提交事务的数据不丢失
若事务失败，undo log 保证可以回滚到修改前的状态
binlog 保证了主从复制的数据一致性和时间点恢复能力

5. 三大日志的核心区别

特性	redo log	undo log	binlog
所属层级	InnoDB 存储引擎层	InnoDB 存储引擎层	MySQL 服务器层
主要作用	保证事务持久性（崩溃恢复）	保证事务原子性（回滚）+ MVCC	主从复制 + 时间点恢复
日志类型	物理日志（数据页修改）	逻辑日志（操作逆过程）	逻辑日志（SQL 或行修改）
生命周期	循环写（可覆盖）	事务提交后可回收	追加写（不覆盖）
刷盘时机	事务执行中实时写入，提交时确保持久化	随数据页异步刷盘	事务提交时写入
存储引擎依赖	仅 InnoDB 支持	仅 InnoDB 支持	所有引擎都支持