MySQL三大核心日志为Undo Log、Redo Log和Binlog：Undo Log在InnoDB层实现逻辑回滚与MVCC，Redo Log以物理方式保障崩溃恢复下的持久性，Binlog在Server层支持复制与时间点恢复，三者分层协作共同实现ACID。
MySQL 日志系统面试最常考的，就是Undo Log、Redo Log 和 Binlog 这三大核心日志。它们分属不同层级、承担不同职责，共同支撑事务的 ACID 特性与高可用能力。理解它们的定位、原理和协作关系，是回答日志类问题的关键。
Undo Log：保证原子性与 MVCC 的逻辑回滚日志
Undo Log 是 InnoDB 存储引擎层实现的逻辑日志，记录的是“数据修改前的样子”。比如执行 UPDATE t SET name='B' WHERE id=1，Undo Log 就会记下 name='A' 这个旧值；执行 DELETE，它就记下对应的 INSERT 语句。
它的核心作用有两个：
- 支持事务回滚：事务执行中出错或显式执行
ROLLBACK时，InnoDB 用 Undo Log 把已改的数据“倒回去” - 支撑 MVCC（多版本并发控制）：未提交事务产生的 Undo Log，为其他并发事务提供快照读（如
SELECT）所需的旧版本数据，避免加锁阻塞
注意：Undo Log 不是立刻删除的。事务提交后，它进入待清理队列，由后台线程 purge thread 异步回收；它以段（rollback segment）方式组织，每个段可管理多个事务的回滚信息。
Redo Log：保障持久性的物理重做日志
Redo Log 也是 InnoDB 层的日志，但它是物理日志，记录的是“某个数据页上某几个字节被改成了什么”，比如“page 5 的 offset 100 处写入了 0x1A2B”。它的目标只有一个：崩溃恢复时，把已提交但还没刷到磁盘的数据页补全。
关键特点包括：
- 固定大小、循环写入：通常配置为多个小文件（如 ib_logfile0/ib_logfile1），写满后从头覆盖，靠 checkpoint 机制推进安全写入点
- Write-Ahead Logging（WAL）：所有数据页修改必须先写 Redo Log，再更新 Buffer Pool；这大幅减少随机磁盘写，提升性能
- 刷盘策略可控：通过
innodb_flush_log_at_trx_commit参数调节（0/1/2），平衡性能与安全性
没有 Redo Log，数据库一旦宕机，Buffer Pool 中未落盘的已提交事务就会丢失，违反持久性。
Binlog：用于复制与恢复的 Server 层逻辑日志
Binlog 是 MySQL Server 层生成的逻辑日志，记录的是“执行了哪条 SQL”或“哪一行发生了什么变化”（取决于 binlog_format 设置为 STATEMENT/ROW/MIXED）。它不记录查询类语句（SELECT、SHOW），只记录影响数据的 DML 和 DDL。
主要用途有三个：
- 主从复制：从库拉取并重放主库的 Binlog，实现数据同步
- 基于时间点的恢复（PITR）：配合备份，可恢复到故障前任意时刻的状态
- 审计与变更追踪：DBA 可解析 Binlog 查看历史变更行为
注意：Binlog 本身不具备崩溃恢复能力——它不包含未提交事务的信息，也不参与 InnoDB 内部的事务状态管理。它和 Redo Log 的协作靠两阶段提交（2PC）保证一致性：事务先写 Redo Log（Prepare 状态），再写 Binlog，最后将 Redo Log 标记为 Commit。
三者对比与协同关系
面试中常被要求画表对比，核心差异如下：
- 层级不同：Undo/Redo 是 InnoDB 引擎层日志；Binlog 是 Server 层日志
- 内容类型不同：Undo 是逻辑日志（反向操作）；Redo 是物理日志（页级变更）；Binlog 是逻辑日志（SQL 或行事件）
- 生命周期不同：Undo 提交后异步清理；Redo 循环复用；Binlog 按配置保留天数或大小自动轮转
- 功能不可替代：少任何一个，ACID 就不完整——Undo 保原子性，Redo 保持久性，Binlog 保可复制性与可恢复性
当面试官问“为什么需要三套日志”，本质是在考察你是否理解 MySQL 架构分层设计的思想：Server 层专注协议与逻辑，引擎层专注存储与事务，各司其职又紧密协作。
