redo log、undo log 和 binlog 有什么区别？为什么要两阶段提交？

详细解析#

三种日志对比#

redo log 的刷盘策略见 ACID 是怎么实现的，undo log 在 MVCC 中的作用见 MVCC 是怎么实现的。

binlog 有三种格式：STATEMENT 记录 SQL 原文，日志小，但 UUID()、SYSDATE()、不带 ORDER BY 的 UPDATE ... LIMIT 这类结果不确定的语句，在从库上执行的结果可能和主库不同；ROW 记录每一行修改前后的值，准确，但批量更新时日志很大；MIXED 由 MySQL 自动选择。MySQL 5.7.7 起默认是 ROW。

为什么要两份日志#

binlog 属于 Server 层，所有引擎都能用，早期默认的 MyISAM 引擎没有崩溃恢复能力；InnoDB 是另一家公司开发、后来才接入 MySQL 的引擎，用自己的 redo log 实现了崩溃恢复。两者分工不同，谁也替代不了谁：

• binlog 不能用于崩溃恢复：它记录的是逻辑操作，不知道哪些修改已经写进了数据页、哪些还没有
• redo log 不能用于复制和归档：它是 InnoDB 私有的物理日志，循环写会覆盖旧内容，保存不了完整的历史

两阶段提交#

开启 binlog 时，InnoDB 和 binlog 通过内部的 XA 事务协调提交：

执行 UPDATE：修改缓冲池中的页，写 undo log，写 redo log（在内存中）
        │
提交 ┌─ 1. prepare：redo log 写入 prepare 状态和事务的 XID，刷盘
     ├─ 2. 写 binlog（带着同一个 XID），刷盘
     └─ 3. commit：在 redo log 中把事务标记为已提交

如果不用两阶段提交，两份日志各写各的，中间一旦崩溃就会不一致：

• 先写 redo log 再写 binlog：redo log 写完后崩溃，重启后主库靠 redo log 恢复了这次修改，但 binlog 里没有，从库和用 binlog 恢复出来的库都少了这笔数据
• 先写 binlog 再写 redo log：binlog 写完后崩溃，主库上这个事务没有提交、被回滚了，但 binlog 里有，从库反而多出了这笔数据

崩溃恢复时怎么判断#

重启时 InnoDB 扫描 redo log，按事务的状态处理：

1. 已经有 commit 标记：事务已提交，恢复它
2. 只有 prepare：拿 XID 去 binlog 里找。binlog 里有这个事务完整的记录，说明 binlog 已经写好、可能已经传给了从库，就提交；找不到，说明 binlog 没写完，就回滚
3. 还没到 prepare：事务没进入提交流程，用 undo log 回滚

判断的标准是 binlog 有没有写成功：binlog 写成功才算真正提交，主库和从库就能保持一致。也正因为如此，第 3 步的 commit 标记不需要立即刷盘。

面试官可能追问#

易错点#

• 两阶段提交的"两阶段"指 redo log 的 prepare 和 commit，binlog 写在两者之间
• redo log 是循环写的，不能用来恢复任意时间点的数据，那要靠全量备份加 binlog
• undo log 本身的修改也会写 redo log，崩溃恢复时先靠 redo log 恢复 undo log，再用 undo log 回滚未提交的事务
• STATEMENT 格式下 NOW() 是安全的，因为 binlog 会记录语句的执行时间；UUID()、SYSDATE() 才会导致主从不一致