MySQL 的三大日志可以这样理解：Undo Log 管回滚、Redo Log 管崩溃恢复、Binlog 管主从复制和数据归档，它们分别属于 InnoDB 引擎层（前两者）和 Server 层（后者），配合起来才保证了事务的原子性、持久性和主从数据一致性。
1. 引言：MySQL 为什么需要这么多日志？
在使用 MySQL 时经常听到这样几个名词：
- undo log
- redo log
- binlog
? 不就是写数据库吗？为什么还要搞这么多日志？
其实，本质原因只有一个：
???? 为了保证事务安全、数据不丢失、主从一致性。
MySQL 的三大日志，分别从三个维度解决问题：
| 日志 | 解决问题 |
|---|---|
| undo log | 事务回滚 |
| redo log | 崩溃恢复 |
| binlog | 逻辑复制 |
2. Undo Log：事务回滚的“后悔药”
2.1 什么是 Undo Log？
undo log 的核心作用是：
记录数据修改前的状态，用于事务回滚。
通俗理解：
做错事 → 有后悔药 → 能回退
2.2 Undo Log 解决什么问题？
主要解决两类问题：
? 事务回滚（Rollback）
|
1 2 3 |
BEGIN; UPDATE user SET money = 0; ROLLBACK; |
此时通过 undo log 恢复原值。
? MVCC（多版本并发控制）
undo log 是 MVCC 的基础：
- 每次修改生成历史版本
- 不同事务读取不同版本
提高并发性能。
2.3 Undo Log 工作原理
执行更新时：
- 先写 undo log（旧数据）
- 再修改数据页
- 提交事务
示意：
|
1 2 |
旧值 → undo log 新值 → buffer pool |
2.4 Undo Log 的特点
| 特性 | 说明 |
|---|---|
| 类型 | 逻辑日志 |
| 存储 | 表空间 |
| 生命周期 | 事务结束后可清理 |
| 作用阶段 | 事务内 |
3. Redo Log：崩溃恢复的“救命符”
3.1 什么是 Redo Log？
redo log 的核心思想是：
记录“做了什么修改”，用于宕机恢复。
也叫：
WAL（Write Ahead Logging）
先写日志，再写磁盘。
3.2 Redo Log 解决什么问题？
解决：
? MySQL 宕机后数据丢失问题
因为：
- 数据页先在内存中修改
- 磁盘写入较慢
如果宕机，内存数据丢失。
3.3 Redo Log 工作流程
更新流程：
3.4 Redo Log 的物理含义
redo log 记录的是：
对某个数据页做了什么物理修改
例如：
|
1 |
page 10, offset 20, value 3 → 5 |
3.5 Redo Log 的特点
| 特性 | 说明 |
|---|---|
| 类型 | 物理日志 |
| 存储 | ib_logfile |
| 结构 | 循环写 |
| 作用阶段 | 崩溃恢复 |
4. Binlog：主从复制的“桥梁”
4.1 什么是 Binlog？
binlog 是 MySQL Server 层日志：
记录所有对数据库产生影响的逻辑操作。
与 InnoDB 无关。
4.2 Binlog 的作用
主要作用：
? 主从复制
主库写 binlog → 从库重放
? 数据恢复
支持时间点恢复（PITR）
4.3 Binlog 格式
三种格式：
| 格式 | 说明 |
|---|---|
| STATEMENT | SQL 语句 |
| ROW | 行变化（推荐） |
| MIXED | 混合 |
生产环境一般用：
|
1 |
binlog_format = ROW |
4.4 Binlog 写入流程
事务提交时：写 binlog → 刷盘 → 提交
4.5 Binlog 特点
| 特性 | 说明 |
|---|---|
| 层级 | Server 层 |
| 类型 | 逻辑日志 |
| 是否循环 | 否 |
| 用途 | 复制/恢复 |
5. 三大日志协作流程（重点）
以一次 UPDATE 为例：
|
1 |
UPDATE user SET money = 100 WHERE id = 1; |
完整流程：
???? 这就是著名的 两阶段提交（2PC）。
6. 两阶段提交（2PC）
目的：
保证 redo log 和 binlog 一致
阶段一（Prepare）：
|
1 |
redo log prepare |
阶段二（Commit）：
|
1 2 |
binlog 写入 redo log commit |
防止主从不一致。
7. 三大日志对比总结
| 维度 | undo log | redo log | binlog |
|---|---|---|---|
| 层级 | InnoDB | InnoDB | Server |
| 类型 | 逻辑 | 物理 | 逻辑 |
| 作用 | 回滚/MVCC | 崩溃恢复 | 复制/恢复 |
| 生命周期 | 短 | 长 | 长 |
| 是否循环 | 否 | 是 | 否 |
8. 常见面试题解析
Q1：为什么 redo 是物理，binlog 是逻辑？
- redo：页级修改 → 快速恢复
- binlog：SQL/行 → 跨引擎复制
Q2：只有 redo 行不行？
? 不行
redo 不能做主从复制。
Q3：undo 会一直存在吗？
? 不会
Purge 线程定期清理。
Q4：宕机时如何恢复？
- 未提交 → undo 回滚
- 已提交 → redo 重放
9. 生产环境建议
推荐配置
|
1 2 3 |
innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 binlog_format = ROW |
保证最强一致性。
10. 总结
三大日志分工明确：
- undo：负责“后悔”
- redo：负责“复活”
- binlog：负责“传播”
undo 保证回滚，redo 保证不丢，binlog 保证同步。
