redo log是物理日志，记录页号、偏移量和新值，用于崩溃恢复；undo log是逻辑日志，记录回滚操作，支持事务回滚和mvcc；二者生命周期不同，redo循环覆盖，undo需purge线程异步清理。
redo log 是物理日志，只管“页上哪块字节被改成了啥”
它不关心 SQL 逻辑，也不记录行、字段或主键——只记录“页号 123、偏移量 48、新值 0xABCDEF”这种底层磁盘操作。所以崩溃恢复时，MySQL 只需按顺序重放这些物理修改，就能把已提交但还没刷盘的数据页“追回来”。
常见错误现象：设置 innodb_flush_log_at_trx_commit=2 后突然断电，可能丢失最后 1 秒的已提交事务（因为日志只写到 OS buffer，没真正落盘）；设为 0 更危险，连 buffer 都可能丢。
实操建议：
• 生产环境务必设为 1（默认值），确保每次 COMMIT 都触发 fsync；
• 调大 innodb_log_file_size（比如从默认 48MB 提到 256MB）可减少 checkpoint 频率，缓解写放大；
• 别手动删 ib_logfile0 或 ib_logfile1——MySQL 启动时会校验并报错 Invalid log file size。
undo log 是逻辑日志，专为“回滚 + 多版本”而生
它记录的是“怎么撤销”，比如一条 UPDATE user SET name='Alice' WHERE id=1，undo log 就记下“把 name 改回旧值 'Bob'”；如果是 INSERT，就记“删掉这行”；DELETE 则记“重新插入原数据”。这种设计让它天然支持事务回滚和 MVCC。
使用场景：高并发读多写少业务中，大量 SELECT 不加锁却能读到快照，靠的就是 undo log 构建的版本链（通过隐藏字段 DB_ROLL_PTR 串起来）。
实操建议：
• 开启在线收缩：设 innodb_undo_log_truncate=1，避免 undo 表空间无限膨胀；
• 检查长期未提交事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600，这类事务会阻塞 purge 线程清理 undo，拖慢整个系统；
• innodb_rollback_segments 默认 128，一般不用调，除非遇到大量短事务争用 undo slot 导致 Lock wait timeout exceeded。
两者生命周期和清理机制完全不同
redo log 是循环覆盖的：写满 ib_logfile0 就切到 ib_logfile1，再写满又绕回开头——只要 checkpoint 已推进，旧日志就自动失效，无需人工干预。
undo log 则“死得很慢”：事务提交后，它的日志不会立刻删，得等所有依赖该版本的活跃事务（包括正在做快照读的查询）都结束，purge 线程才会异步回收。这意味着一个长事务（哪怕只是个慢查询）可能让 undo 占着几 GB 空间不放。
容易踩的坑：
• 把 innodb_max_purge_lag 设太高（比如 1000 万），会导致 purge 延迟严重，undo 表空间持续增长甚至填满磁盘；
• 误以为 TRUNCATE TABLE 能清空 undo——它不走事务，不生成 undo log，但也不会释放已有 undo 空间；
• 在 MySQL 5.7 中用 innodb_undo_tablespaces=0（即共享表空间），一旦 undo 膨胀就只能 dump & reload，8.0+ 推荐用独立 undo 表空间（innodb_undo_tablespaces > 0）便于管理。
binlog 和它们不是一回事，别混进事务日志体系
redo/undo 是 InnoDB 引擎层日志，只对 InnoDB 表生效；binlog 是 Server 层日志，记录的是 SQL 语句或行变更事件，用于主从复制和 PITR（基于时间点恢复）。三者协作关系是：事务提交时，先写 redo（保证崩溃可恢复），再写 binlog（保证复制一致性），最后才在引擎层标记事务完成（两阶段提交）。
关键区别点：
• binlog 是追加写，永不覆盖，靠 expire_logs_days 或 PURGE BINARY LOGS 手动清理；
• redo log 文件名固定为 ib_logfile*，undo log 存在 undo_001 等独立表空间文件或 ibdata1 里，而 binlog 是 mysql-bin.000001 这类；
• 查看当前状态：SHOW ENGINE INNODB STATUS\G 能看到 undo 段和 purge 进度，SHOW MASTER STATUS 看 binlog 位置，SELECT * FROM performance_schema.log_status（8.0.33+）可查 redo 日志序列号。
实际调优时，最常被忽略的是 undo 的“滞留时间”——它不像 redo 那样有明确的大小上限，而是被业务侧的慢查询、未关闭连接、监控脚本里的长事务悄悄拖住。盯紧 INNODB_TRX 和 INNODB_METRICS 里的 undo_truncations、purge_invoked 这几个指标，比调参数更管用。
