极高 困难
redo-log与binlog#
一句话答案#
redo log 是 InnoDB 的物理日志保证崩溃恢复（WAL），binlog 是 Server 层的逻辑日志用于主从复制和数据恢复。
核心要点
| 日志 | 所属层 | 作用 | 格式 | 写入时机 |
|---|---|---|---|---|
| redo log | InnoDB 引擎层 | 崩溃恢复（保证持久性） | 物理日志（记录数据页的物理修改） | 事务执行过程中持续写 |
| undo log | InnoDB 引擎层 | 事务回滚 + MVCC 版本链 | 逻辑日志（记录逆操作） | 事务执行过程中持续写 |
| binlog | MySQL Server 层 | 主从复制 + 数据归档恢复 | 逻辑日志（SQL语句或行变更） | 事务提交时一次性写 |
关键区别：
- redo log 是循环写（固定大小，写满后从头覆盖），binlog 是追加写（可保留完整历史）
- redo log 是 InnoDB 引擎私有，binlog 是 MySQL Server 层，所有引擎共享
- redo log 用于实例恢复（宕机后恢复内存数据），binlog 用于数据恢复（时间点恢复）和主从同步
面试回答（2分钟版）
redo log 和 binlog 是不同层面的日志。redo log 是 InnoDB 引擎层的物理日志，采用 WAL 机制，事务执行中先把数据页修改写入 redo log buffer 再刷盘，宕机后重放 redo log 把未刷盘的脏页补回来，保证持久性。redo log 固定大小循环写入，比如 4 个 1GB 文件写满从头覆盖，通过 checkpoint 推进腾出空间。binlog 是 Server 层的逻辑日志，所有引擎共享，记录 SQL 语句或行变更，追加写模式保留完整变更历史，用于主从复制和时间点恢复。binlog 有三种格式：STATEMENT 记录原始 SQL、ROW 记录行变更前后值、MIXED 混合模式，生产环境推荐 ROW。两者通过两阶段提交保证一致性：先写 redo log 置为 prepare，再写 binlog，最后 redo log 置为 commit，任何一步失败都可对比两个日志判断事务是否提交，避免主从数据不一致。
追问与易错
追问方向：
- “为什么需要两种日志？”→ redo log 是 InnoDB 引擎层的物理日志，保证崩溃恢复（持久性）；binlog 是 Server 层的逻辑日志，保证主从复制和时间点恢复；两者职责不同、层次不同，缺一不可
- “redo log 大小固定怎么办写满了？”→ redo log 循环写，写满时触发 checkpoint 推进，将 Buffer Pool 中的脏页刷盘后释放 redo log 空间；刷盘期间写入会被阻塞，所以 redo log 不宜设太小
- “binlog 有哪几种格式？”→ 三种：STATEMENT 记录原始 SQL（日志小但主从可能不一致）、ROW 记录行变更前后值（精确但日志大）、MIXED 混合模式；生产环境推荐 ROW 格式确保主从数据一致
易错点：
- ❌ “有了 binlog 为什么还需要 redo log”——binlog 不能恢复未提交的页修改
- ❌ 混淆 redo log 和 undo log——redo 保证持久性（重做），undo 保证原子性（回滚）