redo log、undo log 和 binlog 分别解决崩溃恢复、事务回滚与一致性读、主从同步与数据归档；三者分属不同层级，协同工作而非替代。

MySQL 的日志系统中，redo log、undo log 和 binlog 各司其职，分别解决崩溃恢复、事务回滚与一致性读、主从同步与数据归档三大核心问题。它们不在同一层级，也不互相替代，而是协同工作——理解它们的分工和协作逻辑，比死记格式更重要。

redo log：InnoDB 的“崩溃急救包”

它是 InnoDB 存储引擎层的物理日志，只记录“在哪个数据页、哪个偏移量上做了什么修改”，比如“将第 5 号页的第 128 字节位置由 0x0A 改为 0x0B”。这种设计带来两个关键优势：

• 顺序写入：日志追加到文件末尾，避免随机 IO，性能远高于直接刷脏页
• 体积小、恢复快：不存完整页，只存变化，重启时能快速重放已提交但未落盘的修改

它默认以循环方式使用（如 ib_logfile0/ib_logfile1），靠 write pos 和 checkpoint 两个指针管理可用空间。一旦 write pos 追上 checkpoint，更新就会阻塞，必须先推进 checkpoint（即把对应脏页刷入磁盘）才能继续。

是否真正落盘，由参数 innodb_flush_log_at_trx_commit 控制：
值为 1（默认）：每次 commit 都 fsync 到磁盘， crash-safe；
值为 0 或 2：依赖系统缓存或定时刷盘，有丢事务风险。

undo log：事务的“时光倒流按钮”

它也是 InnoDB 层的日志，但属于逻辑日志，记录的是“修改前的样子”，例如“user 表中 id=100 的 name 原值是 'Alice'”。主要用途有两个：

• 事务回滚：当执行 ROLLBACK，就用 undo log 把数据恢复到事务开始前的状态
• MVCC 快照读：SELECT 不加锁时，会根据事务的 Read View 找到对应版本的 undo 记录，实现非阻塞读

MySQL 5.7+ 支持独立 undo 表空间（innodb_undo_tablespaces），便于管理和清理。事务提交后，undo 日志不会立即删除，而是进入 purge 队列，由后台 purge 线程判断是否还有活跃事务需要它，再决定回收。

binlog：MySQL Server 层的“操作录像带”

它位于 Server 层，所有存储引擎共用，记录的是逻辑变更，比如 “UPDATE orders SET status='shipped' WHERE id=12345”。格式可选三种：

• STATEMENT：记 SQL 原文，省空间但有函数不一致风险（如 UUID()、NOW()）
• ROW（推荐）：记每一行变更的前后镜像，主从强一致，适合审计和闪回
• MIXED：自动切换，但行为不可控，生产环境慎用

binlog 不用于崩溃恢复，但承担两大关键任务：
– 主从复制：从库拉取并重放 binlog 实现数据同步
– 时间点恢复（PITR）：配合全量备份 + binlog，可恢复到任意秒级时间点

它的生命周期由 expire_logs_days 或 binlog_expire_logs_seconds（8.0.28+）控制，支持按大小（max_binlog_size）自动轮转。

三者如何协同？以一条 UPDATE 为例

当执行 UPDATE t SET c=c+1 WHERE id=1; 时，流程如下：

• InnoDB 先在 Buffer Pool 中修改数据页，并生成一条 redo log（记物理改动），写入 redo log buffer
• 同时生成一条 undo log（记 c 修改前的旧值），存入 undo 表空间
• 事务提交前，redo log buffer 按策略刷入磁盘；commit 时，Server 层将该语句的逻辑变更写入 binlog 文件
• 最后 InnoDB 将事务标记为已提交（两阶段提交机制确保 redo 与 binlog 一致性）

若此时崩溃，重启后 InnoDB 用 redo log 恢复已提交但未刷盘的页；若要重建从库或回滚某次误操作，则需解析 binlog；若事务中途失败，则用 undo log 回退。