mysql崩溃恢复仅在启动时检测到异常关闭（如kill -9、断电）且满足redo校验失败、prepared事务残留或checkpoint不匹配等前提时触发；恢复分两阶段：先从checkpoint扫描redo日志前滚已提交变更，再基于重建字典扫描undo回滚未提交事务，顺序不可逆。
崩溃恢复触发时机：不是“启动就跑”，而是有明确前提
MySQL 启动时并不会无条件执行崩溃恢复。只有当 innodb_redo_log_checksums 验证失败、redo log 中存在未刷盘的 PREPARED 事务、或 ibdata1 头部的 LOG_CHECKPOINT 位置与当前 redo log 文件不匹配时，InnoDB 才会判定“上次未正常关闭”，进而进入崩溃恢复流程。
常见误判场景包括：强制 kill -9 mysqld、宿主机断电、容器被 OOM-killer 杀掉——这些都会导致 redo 日志未完成刷盘，触发恢复；而正常执行 mysqladmin shutdown 或 SERVICE mysql stop 则不会触发。
两阶段恢复过程：redo 扫描 + undo 回滚，顺序不可逆
崩溃恢复本质是两个串行阶段，不能跳过或并行：
-
第一阶段（redo 扫描）：InnoDB 从
ib_logfile0的checkpoint位置开始顺序读取 redo 日志，将所有已提交但未写入数据页的变更（脏页）重新应用到 buffer pool 中。这一步只做“前滚”，不涉及事务状态判断。 -
第二阶段（undo 回滚）：扫描
undo log段，对所有处于TRX_STATE_ACTIVE状态但未写入 binlog（即未通过两阶段提交 commit）的事务，逐条回滚其修改。这个阶段依赖第一阶段重建后的字典和页结构，因此必须等字典加载完成后才开始。
注意：innodb_force_recovery=3 就是跳过第二阶段，直接让实例以只读方式上线——此时未提交事务的修改仍保留在数据页中，但无法再被提交或回滚。
数据字典锁为什么卡住所有查询？这不是 bug，是安全边界
崩溃恢复过程中，SHOW TABLES、SELECT FROM information_schema.tables 甚至 SELECT 1 都会卡在 Waiting for table metadata lock，根本原因在于 InnoDB 在 dict_boot() 函数入口就持有全局 MDL_EXCLUSIVE 锁，且该锁直到整个字典缓存（TDC）重建并校验完毕才释放。
这个锁无法绕过，因为：
- 系统表如
mysql.columns、mysql.tables的物理页可能损坏或版本错乱，必须先用 redo 和 undo 修复后再加载进内存字典； - 若允许并发 SELECT，InnoDB 可能按旧字典定义解析新页结构，造成字段偏移错位，直接触发
Assertion failure in file dict0boot.cc； - 锁持有时间取决于实际恢复工作量：大
innodb_log_file_size→ 更多 redo 要扫描；小innodb_buffer_pool_size→ 更多磁盘 IO；大量未清理 undo → 回滚耗时长。
如何缩短崩溃恢复时间？关键不在调参，而在避免它发生
真正影响恢复耗时的不是 innodb_fast_shutdown 这类开关，而是日常运维中是否压住了风险源：
- 禁用
innodb_fast_shutdown=2（默认），改用=1或=0：前者确保 undo 清理完成，后者强制刷脏页+purge 全部完成，虽延长关机时间，但极大缩短下次启动恢复耗时； - 监控
SHOW ENGINE INNODB STATUS\G中TRANSACTIONS小节的History list length，持续高于 10000 表明 undo 积压严重，需检查长事务或 purge 线程是否被阻塞； - 避免在业务高峰期执行大事务（如全表 UPDATE/DELETE），这类事务崩溃后会拖慢整个恢复流程，因为 undo 回滚是单线程顺序执行的；
-
innodb_log_file_size不宜过大（建议 ≤ 1GB），否则 redo 扫描阶段耗时呈线性增长，且无法并行。
崩溃恢复本身没有“优化空间”，它的设计目标就是强一致而非快——你看到的卡顿，其实是 InnoDB 在用时间换数据安全。
