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 = ONDDL 操作（如
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 的设计目标根本不同：一个管“宕机后能不能恢复”，一个管“运行时能不能读一致、回得回去”。混淆二者职责，容易在调优时南辕北辙。
