redo log 是 crash recovery 的救命稻草
MySQL 崩溃后能不丢数据，全靠
redo log。它不是记“SQL语句”，而是记“某个数据页（page）的第N个字节改成了什么值”——典型的物理日志。只要事务提交过，
redo log里就一定有重做信息，哪怕对应的数据页还没刷到磁盘（
ibdata1或独立表空间），重启后 InnoDB 就能靠它把没落盘的修改补上。 写入时机严格：在脏页刷盘前、事务 commit 前，必须先写入
redo log（WAL，Write-Ahead Logging） 文件固定大小 + 循环覆盖：
innodb_log_file_size决定单个日志文件大小，
innodb_log_files_in_group决定几个文件组成一组；写满就绕回开头，旧日志被覆盖的前提是对应数据页已刷盘 常见坑：调大
innodb_log_file_size后不能直接改配置重启，必须先停库 → 删除旧日志文件（
ib_logfile0/1）→ 再启动，否则报错
Log file .*/ib_logfile0 is of different size
undo log 是回滚和 MVCC 的底层支撑
undo log不是为崩溃恢复设计的，它是给事务自己用的：回滚时按记录反向操作，读取时提供快照版本。它存的是逻辑日志，比如“把 id=5 的 name 从 'Alice' 改回 'Bob'”，而不是物理偏移量。 存储位置在 InnoDB 表空间内，可能是系统表空间（
ibdata1）或独立的 undo 表空间（启用
innodb_undo_tablespaces后） 每个事务都有自己的 undo segment，事务提交后不会立刻删，得等 Purge 线程确认没有活跃事务依赖这些旧版本（比如长事务还在读快照），才真正清理 容易踩的坑：
innodb_max_purge_lag设太小会导致 purge 慢拖慢 DML；而设太大又可能让 undo 表空间暴涨，尤其遇到大量 delete/update 且有长事务时
redo 和 undo 怎么配合完成一次 update
执行
UPDATE t SET name='Tom' WHERE id=1时，InnoDB 实际走的是“先记 undo，再改内存，最后记 redo”三步： 分配 undo slot，写入原值（
name='Bob'）到 undo log，生成 rollback pointer 在 buffer pool 中修改对应数据页，标记为 dirty 把该页的物理变更（如 page_no + offset + new_value）写入
redo log buffer，随后刷盘（受
innodb_flush_log_at_trx_commit控制） commit 时，
redo log写入 prepare 状态 →
binlog写入 →
redo log写入 commit 状态（两阶段提交）
注意：undo 记录的是“怎么撤销”，redo 记录的是“怎么重做”，二者不是互逆操作，也不能互相替代——一个管回退，一个管恢复。
为什么 binlog 不能代替 redo 或 undo
binlog是 Server 层日志，只记录逻辑变更（如原始 SQL 或行镜像），不包含事务 ID、回滚指针、页结构等 InnoDB 内部信息，所以它既不能支持事务回滚（没旧值），也不能做崩溃恢复（无法定位到具体页和偏移）。 主从复制靠
binlog，但主库 crash 后，从库同步中断点可能比主库实际持久化的数据还靠前——必须靠
redo log把主库拉到一致状态，再继续同步
binlog_format=ROW虽然记录了行变更，但它不记录事务开始/结束边界、隔离级别、锁信息，更不参与 MVCC 版本链构建 误删数据想闪回？
binlog可以解析出 delete 语句，但若没开
binlog_row_image=FULL，可能缺失完整前镜像，undo log 此时也早被 purge —— 所以关键业务务必评估
innodb_undo_retention和备份策略
真正要稳住事务行为，三个日志缺一不可：undo 定义“我能回到哪”，redo 保证“我提交的不会丢”，binlog 确保“别人能跟上我”。别指望删掉其中一个还能安全跑。
