[面试题] binlog、redolog 和 undolog 的区别？
📖 版块 A：知识讲解版 (温故知新)
在 MySQL（尤其是 InnoDB 引擎）中，这三种日志各司其职，共同保证了事务的 ACID 特性以及数据的高可用：
-
binlog（归档日志）
- 所属层级：MySQL Server 层，所有存储引擎共有。
- 类型：逻辑日志。记录的是 SQL 语句（Statement）或行数据的变更（Row）。
- 作用：主从复制（Replication）和数据恢复（Point-in-time recovery）。
- 写入时机：事务提交时一次性写入。
-
redolog（重做日志）
- 所属层级：InnoDB 存储引擎层。
- 类型：物理日志。记录的是“在某个数据页上做了什么修改”。
- 作用：保证事务的持久性（Durability），实现 Crash-Safe 能够根据日志恢复未刷盘的数据。
- 特点：空间固定，循环写入（Circular buffer）。
-
undolog（回滚日志）
- 所属层级：InnoDB 存储引擎层。
- 类型：逻辑日志。记录的是数据的反向操作（如 Insert 对应 Delete）。
- 作用：保证事务的原子性（Atomicity）和实现 MVCC（多版本并发控制）。
- 特点：用于事务回滚和读取老版本快照。
🎤 版块 B：面试实战版 (高手逐字稿)
Q：binlog、redolog 和 undolog 区别是什么？
🧠 破局思路：面试官不仅想看你是否知道这三个名词，更想考察你对 InnoDB 事务实现原理的深度理解。区分度的关键点在于：能不能讲清楚 “物理日志与逻辑日志的区别” 以及 “为什么需要两阶段提交（2PC）” 来保证日志间的一致性。
💬 高手逐字稿：
关于这三种日志，我们可以从它们在事务流程中扮演的角色来深度区分。
首先是 undolog，它是实现事务原子性的关键。在事务执行过程中，InnoDB 会把修改前的旧版本数据记录到 undolog 里。如果事务因为异常需要回滚，或者我们手动执行了 ROLLBACK，引擎就会利用 undolog 把数据逻辑恢复到修改前的状态。同时，它也是 MVCC 实现快照读的核心，让不同事务能看到对应的历史版本。
其次是 redolog，它主要解决的是持久化效率和 Crash-Safe 问题。因为随机 IO 刷盘很慢，InnoDB 采用 WAL（Write-Ahead Logging）机制，先将修改记录在 redolog 缓冲区并顺序写入磁盘。即使数据库宕机，只要 redolog 还在，重启后就能通过物理日志把数据页恢复。它是循环写的，空间有限，主要负责保障事务的持久性。
最后是 binlog。它属于 Server 层，是逻辑日志。跟 redolog 最大的不同是，binlog 是追加写的，记录了全量的操作，主要用于主从同步和全量备份恢复。
这里其实涉及到一个高手经常关注的细节：既然 redolog 和 binlog 都要记录数据的变更，那怎么保证它们的一致性？
MySQL 引入了“两阶段提交”协议。在事务提交时，先由 InnoDB 写入 redolog 并标记为 prepare 状态，接着由 Server 层写入 binlog，最后再把 redolog 改为 commit 状态。如果在 binlog 写入后、redolog 提交前发生宕机，重启检查时，发现 binlog 已经完整，就会自动提交 redolog。这样就避免了“通过 binlog 恢复出来的数据”与“主库磁盘里的物理数据”不一致的问题。
总结来说：undolog 负责回滚和快照，redolog 负责掉电后的物理恢复，而 binlog 负责集群间的数据同步和长期的历史恢复。