1. 引言：MySQL 为什么需要这么多日志？

在使用 MySQL 时经常听到这样几个名词：

• undo log
• redo log
• binlog

? 不就是写数据库吗？为什么还要搞这么多日志？

其实，本质原因只有一个：

???? 为了保证事务安全、数据不丢失、主从一致性。

MySQL 的三大日志，分别从三个维度解决问题：

2. Undo Log：事务回滚的“后悔药”

2.1 什么是 Undo Log？

undo log 的核心作用是：

记录数据修改前的状态，用于事务回滚。

通俗理解：

做错事 → 有后悔药 → 能回退

2.2 Undo Log 解决什么问题？

主要解决两类问题：

? 事务回滚（Rollback）

此时通过 undo log 恢复原值。

? MVCC（多版本并发控制）

undo log 是 MVCC 的基础：

• 每次修改生成历史版本
• 不同事务读取不同版本

提高并发性能。

2.3 Undo Log 工作原理

执行更新时：

1. 先写 undo log（旧数据）
2. 再修改数据页
3. 提交事务

示意：

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 记录的是：

对某个数据页做了什么物理修改

例如：

3.5 Redo Log 的特点

4. Binlog：主从复制的“桥梁”

4.1 什么是 Binlog？

binlog 是 MySQL Server 层日志：

记录所有对数据库产生影响的逻辑操作。

与 InnoDB 无关。

4.2 Binlog 的作用

主要作用：

? 主从复制

主库写 binlog → 从库重放

? 数据恢复

支持时间点恢复（PITR）

4.3 Binlog 格式

三种格式：

生产环境一般用：

4.4 Binlog 写入流程

事务提交时：写 binlog → 刷盘 → 提交

4.5 Binlog 特点

5. 三大日志协作流程（重点）

以一次 UPDATE 为例：

完整流程：

???? 这就是著名的 两阶段提交（2PC）。

6. 两阶段提交（2PC）

目的：

保证 redo log 和 binlog 一致

阶段一（Prepare）：

阶段二（Commit）：

防止主从不一致。

7. 三大日志对比总结

8. 常见面试题解析

Q1：为什么 redo 是物理，binlog 是逻辑？

• redo：页级修改 → 快速恢复
• binlog：SQL/行 → 跨引擎复制

Q2：只有 redo 行不行？

? 不行

redo 不能做主从复制。

Q3：undo 会一直存在吗？

? 不会

Purge 线程定期清理。

Q4：宕机时如何恢复？

• 未提交 → undo 回滚
• 已提交 → redo 重放

9. 生产环境建议

推荐配置

保证最强一致性。

10. 总结

三大日志分工明确：

• undo：负责“后悔”
• redo：负责“复活”
• binlog：负责“传播”

undo 保证回滚，redo 保证不丢，binlog 保证同步。