是，MySQL崩溃恢复时InnoDB自动调用Redo Log重放已提交事务；启动时扫描ib_logfile0/1，从last_checkpoint_lsn开始逐条应用物理页修改，全过程由InnoDB引擎内部恢复线程完成，SQL层不参与。
崩溃恢复时MySQL是否主动调用Redo Log？
不调用。InnoDB在启动时自动触发崩溃恢复流程，执行器（即SQL层）完全不参与——它甚至还没初始化。重做（replay）由InnoDB存储引擎内部的恢复线程完成，和查询执行、优化器、执行器这些SQL层组件无关。
常见误解是以为START TRANSACTION或COMMIT这类语句会“触发”Redo Log应用，其实它们只影响日志写入行为；而崩溃后的重做是纯引擎级、无SQL上下文的物理页修复过程。
重做阶段实际发生什么？
InnoDB启动后扫描ib_logfile0和ib_logfile1，定位last_checkpoint_lsn（存于日志文件第2/4个block），从此处开始顺序读取所有未被checkpoint覆盖的Redo记录，并逐条应用到对应数据页：
- 每条Redo记录含
space_id、page_no、offset、length和修改内容，直接按字节覆写内存中对应页位置 - 若目标页不在Buffer Pool中，先从磁盘加载（可能触发doublewrite校验）
- 重做不校验事务状态：已提交、未提交、部分写入的事务记录都会被重放；后续才由Undo Log处理未提交事务的回滚
- 重做完成后，Buffer Pool中所有页都达到“崩溃前最后已提交状态”，但可能包含尚未清理的临时变更
哪些配置直接影响重做能否成功？
重做失败往往不是逻辑错误，而是底层文件或配置异常导致引擎无法解析日志流：
-
innodb_log_file_size与磁盘上ib_logfile0实际大小不一致 → 启动报错Log file ./ib_logfile0 is of different size -
innodb_fast_shutdown=2后强制关机 → 虽仍能重做，但change buffer未合并，可能导致索引页逻辑不一致 -
innodb_flush_log_at_trx_commit=0或2→ 事务提交后Redo Log可能未落盘，这部分修改在崩溃后必然丢失（不是重做失败，而是根本没日志可重做） - 手动删除或清空
ib_logfile0/ib_logfile1→ 启动时报Cannot open or create the system tablespace或直接拒绝启动
如何确认重做是否真的发生了？
别看SHOW ENGINE INNODB STATUS，它只反映运行时状态。唯一可靠方式是查错误日志（error.log）：
- 出现
InnoDB: Database was not shut down normally!→ 触发崩溃恢复 - 出现
InnoDB: Doing recovery: scanned up to log sequence number XXX→ 正在重做，末尾数字是当前处理到的LSN - 出现
InnoDB: Starting crash recovery from checkpoint LSN XXX→ 已定位起点，进入重做主循环 - 没有上述日志 → MySQL认为是正常关闭，跳过重做
注意：重做过程不可中断、不可跳过、不可配置开关——只要InnoDB检测到非正常关闭且Redo文件完好，就一定会执行。真正容易被忽略的是日志文件权限问题：MySQL进程对ib_logfile*无读权限时，不会报明显错误，而是静默失败并拒绝启动。
