redo log 通过重放物理修改保证崩溃恢复,undo log 提供逻辑反向操作支撑 mvcc 和回滚;二者目标不同,不可混淆。

redo log 保证崩溃后数据不丢,靠的是“重放”而非“实时刷盘”
MySQL 崩溃重启时,redo log 的作用是把已提交但还没写入磁盘的 INSERT/UPDATE/DELETE 操作重新执行一遍。它不记录最终数据页,而是记录“物理修改”:比如“在表空间第 1234 号页、偏移量 56 处写入 8 字节新值”。
关键点在于:redo log 是顺序写、循环覆盖的,比随机写数据页快得多;它由 innodb_log_file_size 和 innodb_log_files_in_group 控制总大小;默认配置下(如 48MB)撑不住大批量导入,容易触发 log sequence number too high 或拖慢事务提交。
-
innodb_flush_log_at_trx_commit = 1:每次事务提交都fsync到磁盘,最安全,但有明显性能代价 -
= 2:写入 OS 缓存即返回,崩溃可能丢 1 秒内事务(常见于从库或日志类业务) -
= 0:每秒刷一次,崩溃最多丢 1 秒数据,但并发高时可能因缓存积压导致延迟突增
undo log 不是备份,而是为 MVCC 和回滚提供“旧版本链”
undo log 存在 InnoDB 的 undo tablespace(5.7+ 可独立配置),它记录的是“逻辑反向操作”:比如 INSERT 对应一条 DELETE,UPDATE 会生成原字段值,供回滚或一致性读使用。
它直接支撑 SELECT ... FOR UPDATE 和普通 SELECT 的隔离行为:RR 级别下,每个查询看到的是事务开始时刻的“快照”,这个快照就是靠遍历 undo log 链逐步还原出来的。
- 长事务会阻止
undo log回收,导致undo tablespace持续膨胀,甚至触发ERROR 1558 (HY000): Column count of mysql.proc is wrong类间接报错(实际是 undo 空间耗尽) -
innodb_max_undo_log_size(8.0.23+)可自动截断过大的 undo 表空间,但需配合innodb_undo_log_truncate = ON - DDL 操作(如
ALTER TABLE)在 8.0 中默认用 Instant 算法,不走 undo,但加列带默认值或重建表仍会大量写 undo
redo 和 undo 协同工作的典型场景:一个 UPDATE 的完整生命周期
执行 UPDATE t SET v = 'new' WHERE id = 1 时,InnoDB 内部发生:
- 先查到聚簇索引页,把旧记录拷贝进
undo log(生成一个undo log record,并链接到事务的undo log chain) - 在内存中修改数据页,同时把这次修改记入
redo log buffer(如“页 100,偏移 200,写入 new 值”) - 事务提交时,
redo log按配置刷盘;undo log标记为“已提交”,但暂不删除(留给 MVCC 用) - 后续其他事务做快照读,发现该记录被更新过,就顺着
undo log往前找,直到找到可见版本
注意:redo log 刷盘完成才代表事务真正“持久化”,而 undo log 是否清理,只影响空间和历史读能力,不影响已提交事务的正确性。
排查日志异常时,优先看这几个地方
遇到卡顿、主从延迟、或者 SHOW ENGINE INNODB STATUS 里出现大量 LOG WAIT,不要一上来就调大日志文件——先确认瓶颈在哪一侧。
- 查
show global status like 'Innodb_os_log_written':如果每秒写入远超磁盘吞吐(如 >50MB/s 而磁盘只有 120MB/s),说明redo刷盘成瓶颈,可考虑增大innodb_log_file_size或换更快存储 - 查
show global status like 'Innodb_undo_log_pages':持续增长且不回落,大概率有未关闭的长事务,用SELECT * FROM information_schema.INNODB_TRX找出trx_started时间最早的事务 - 错误日志里出现
Cannot allocate memory for the redo log:不是内存不足,而是innodb_log_file_size × innodb_log_files_in_group总大小超过innodb_log_group_home_dir所在分区剩余空间
redo 和 undo 的设计目标根本不同:一个管“宕机后能不能恢复”,一个管“运行时能不能读一致、回得回去”。混淆二者职责,容易在调优时南辕北辙。










