MySQL InnoDB引擎中Redo Log、Binlog、Undo Log的原理、执行顺序

一、核心原理与区别

Redo Log（重做日志）

原理：采用 Write-Ahead Logging（WAL） 机制，记录数据页的物理修改（如“对表空间X的数据页Y的偏移量Z处写入数据A”）。
作用：确保事务的持久性。崩溃恢复时，通过重放redo log恢复已提交事务的数据。
存储：固定大小的循环文件（如ib_logfile0和ib_logfile1），写入方式为顺序写，性能高。

Undo Log（回滚日志）

原理：记录事务修改前的逻辑反向操作（如INSERT对应DELETE，UPDATE对应反向UPDATE）。
作用：
- 支持事务回滚（原子性）。
- 实现多版本并发控制（MVCC），提供历史数据版本。
存储：位于InnoDB表空间（如ibdata1），写入方式为随机读写。

Binlog（二进制日志）
原理：记录所有引起数据变更的SQL语句（如UPDATE user SET name=‘Alice’ WHERE id=1）。
作用：
- 主从复制：主库将binlog传输到从库重放。
- 数据恢复：通过binlog进行时间点恢复。
存储：追加写入文件（如mysql-bin.000001），支持STATEMENT、ROW、MIXED三种格式。

二、执行顺序与协同流程

事务执行顺序（以UPDATE操作为例）：

Redo Log：将Redo Log Buffer持久化到磁盘。
Binlog：将事务的SQL语句写入Binlog文件。

Step 1：记录Undo Log
事务开始时，先记录修改前的旧值到Undo Log（用于回滚或MVCC）。
Step 2：更新内存与Redo Log Buffer
修改数据页（内存中的Buffer Pool）并将变更写入Redo Log Buffer。
Step 3：事务提交时刷盘
Step 4：后台异步刷脏页
通过Checkpoint机制将Buffer Pool中的脏页刷入数据文件。

崩溃恢复流程：
未提交事务：通过Undo Log回滚。
已提交事务：通过Redo Log前滚（重放日志），确保数据持久性。

三、核心作用对比

四、面试关键点总结

1、执行顺序：
Undo Log → Redo Log → Binlog
（事务提交时，先保证Undo Log记录旧值，再通过Redo Log确保持久性，最后写入Binlog用于复制）。

2、崩溃恢复场景：

• 若事务未提交：通过Undo Log回滚。
• 若事务已提交但数据未刷盘：通过Redo Log前滚。

3、MVCC实现：
Undo Log保存历史版本数据，配合ReadView实现非锁定读（如REPEATABLE READ隔离级别）。

4、主从复制依赖：
Binlog记录SQL语句，从库通过重放Binlog实现数据同步。

5、性能优化：

• Redo Log顺序写提升性能。
• Binlog的ROW格式避免主从不一致，但可能增加日志量。

五、典型面试问题

Q：为什么Redo Log能保证崩溃恢复，而Binlog不能？
A：Redo Log记录物理页修改，崩溃后可直接重放；Binlog记录逻辑SQL，无法判断哪些数据已刷盘，需依赖Redo Log的Crash-Safe能力。

Q：Undo Log在MVCC中的作用是什么？
A：Undo Log保存历史版本数据链，事务通过ReadView读取旧版本，实现非锁定读和隔离级别控制。

Q：事务提交时，Redo Log和Binlog的写入顺序为何重要？
A：若先写Binlog后写Redo Log，崩溃时可能导致主从数据不一致（Binlog已同步到从库，但主库未提交）。通过两阶段提交（2PC）确保两者一致性。