innodb_force_recovery不是修复开关，而是只读逃生机制：当InnoDB因页损坏等无法自动恢复时，通过1~6级逐级跳过恢复步骤（如忽略损坏页、禁purge、跳undo回滚、停redo前滚），强制启动以导出数据，但数值越大风险越高，且导出后须重建实例。
innodb_force_recovery 不是自动修复开关，MySQL 崩溃后本就不需要人工“修复”——只要 ibdata1 和 ib_logfile* 文件没被删、没被覆盖、没物理损坏，InnoDB 启动时就会自动完成崩溃恢复。
崩溃重启时 InnoDB 真正做了什么
它不是修表，也不是重建索引，而是按日志“重演”已提交事务、“撤回”未提交事务，目标是让数据页状态回到上一次 checkpoint 的一致点。
关键步骤顺序固定：
- 从
ibdata1第一个 page 读出flushed_lsn（即上次正常关机时的 checkpoint LSN） - 扫描所有
ib_logfile*，找出 LSN >flushed_lsn的 redo 日志段，逐条前滚（redo）应用到 buffer pool 中对应的数据页 - 加载 undo log，对未提交事务执行回滚（undo）
整个过程由 InnoDB 内核自动触发，你看到的“卡在 Starting crash recovery”，大概率只是 I/O 慢或 redo 日志太大（比如几十 GB），不是故障。
哪些情况会真正中断自动恢复
自动恢复失败 ≠ 数据全丢，而是启动流程被底层校验拦住了。常见真实拦截点：
-
Page may be an index page where index id is XXX：某个索引页校验和不匹配，InnoDB 主动中止启动防写坏盘 -
Probable data corruption on page YYY：脏页刷盘中途崩溃，两次写（doublewrite）也救不回来 - 错误日志里反复出现
space=0, page number=ZZZ：损坏发生在系统表空间ibdata1，最危险 - 启动卡死超过 30 分钟且无日志推进：redo log 或 ibdata1 文件本身已损坏（如被 truncate、被误覆盖）
这时才轮到 innodb_force_recovery 上场——但它只负责“绕过检查让你能 SELECT”，不是修复手段。
innodb_force_recovery 必须逐级试，不能跳着设
它的 6 个级别本质是“跳过哪些恢复动作”，数值越大，跳得越多，导出的数据越可能逻辑错乱：
- 设为
1：跳过单个损坏页读取，其他照常；适合space=N, page=xxx明确指向某张用户表 - 设为
2：再禁掉 purge 线程；适合后台清理引发崩溃的场景 - 设为
3：跳过事务回滚；此时未提交事务会被当作已提交，主键冲突、外键断裂风险陡增 - 设为
4及以上：开始跳过 change buffer merge、undo log 扫描、甚至 redo 前滚；ibdata1可能永久性逻辑损坏，不可逆
操作必须严格：my.cnf 中只写一行 innodb_force_recovery = 1，重启 mysqld；若失败，改 2，再试；绝不能直接设 6。
恢复后导出数据，下一步才是关键
用 mysqldump 或 SELECT ... INTO OUTFILE 导出完数据后，别急着改回原配置重启——innodb_force_recovery 启动的实例是只读的，且部分级别（如 3+）已破坏事务一致性，导出的数据不能直接原地导入。
正确做法：
- 停掉当前强制恢复实例
- 备份并移走旧的
ibdata1、ib_logfile*（留作取证） - 初始化全新数据目录，或用 Percona XtraBackup 恢复干净备份
- 把刚才导出的 SQL 或 CSV 导入新实例
最容易被忽略的一点：innodb_force_recovery 是逃生梯，不是维修间——它帮你抢出数据，但抢出来的数据本身可能带伤，验证主键唯一性、外键引用、时间字段连续性，比导出动作本身更耗时。
