innodb_force_recovery不是修复工具，而是只读逃生通道：它不修复损坏页，仅逐级跳过崩溃恢复步骤（如跳过损坏页读取、禁purge、跳undo回滚、停redo前滚）以强制启动导出数据，级别1最安全，6级可能致永久逻辑损坏，必须从1开始逐级尝试，导出后须立即重建实例。
MySQL崩溃后，innodb_force_recovery不是修复工具，而是“只读逃生通道”——它不修数据，只绕过校验让你能 SELECT 出来还能用的数据。真正能抢救多少，取决于损坏位置、日志完整性以及你操作的严谨性。核心原则是：越早停写、越小级别启动、越快导出、越快重建。
先确认是否真需要 innodb_force_recovery
InnoDB 启动时本就会自动恢复（重做已提交事务 + 回滚未提交事务），只要 ibdata1 和 ib_logfile* 文件没被删、没被覆盖、没物理损坏，就无需人工干预。卡在 “Starting crash recovery” 通常是 I/O 慢或 redo 日志太大（比如几十 GB），不是故障。只有错误日志明确出现以下内容，才说明自动恢复被拦住了：
- Page may be an index page where index id is XXX（某张表的索引页校验失败）
- Probable data corruption on page YYY（脏页刷盘中断，doublewrite 也救不回）
- space=0, page number=ZZZ（系统表空间 ibdata1 损坏，最危险）
- 启动卡死超 30 分钟且日志无推进（redo 或 ibdata1 本身已损坏）
严格逐级尝试，从 level 1 开始
6 个级别本质是“跳过哪些恢复动作”，数值越大，跳得越多，导出数据越可能逻辑错乱。必须一级一级试，不能跳设：
- Level 1：跳过单个损坏页读取。适合错误日志明确指向某张用户表（如 space=5, page=123）。这是首选起点，风险最小。
- Level 2：再禁 purge 线程。适合后台清理引发崩溃的场景，常与 level 1 配合使用。
- Level 3：跳过事务回滚。未提交事务会被当作已提交，主键冲突、外键断裂风险陡增，仅当 level 1/2 无效且你接受逻辑不一致时启用。
- Level 4 及以上：开始跳过 change buffer merge、undo 扫描、甚至 redo 前滚。ibdata1 可能永久逻辑损坏，不可逆，仅作最后尝试。
每次修改 my.cnf 后只加一行：innodb_force_recovery = X，重启 mysqld；失败再改下一级，绝不跨级。
只读导出：快、准、全、隔离
一旦能登录 MySQL，立刻执行只读导出，禁止任何写操作：
- 用
mysqldump -uroot -p -A --single-transaction --routines --triggers > full_backup.sql全库导出（--single-transaction 对 InnoDB 有效，保证一致性快照） - 若 level ≥3 导致部分表无法 dump，改用按库/按表导出：
mysqldump -uroot -p dbname tb1 tb2 > dbname_tables.sql - 导出时加
--skip-triggers或--no-create-info避免因触发器或视图定义异常中断 - 导出文件务必存到数据库服务器以外的磁盘（如挂载的备份盘），防止原盘进一步故障
导出后立即重建，别留在原实例上
innodb_force_recovery 是临时逃生模式，绝不能长期运行：
- 导出完成后，关闭 MySQL
- 注释或删除 my.cnf 中的
innodb_force_recovery行 - 将原 data 目录整体重命名备份（如 data_bak_20260520）
- 初始化全新空实例（mysqld --initialize 或 mysql_install_db）
- 启动新实例，导入刚才导出的 SQL 文件
- 导入后立即执行
CHECK TABLE和mysqlcheck -u root -p --all-databases --check验证结构与数据完整性
如果原库启用了独立表空间（innodb_file_per_table=ON），且个别 .ibd 文件损坏但 ibdata1 完好，还可尝试单独恢复单表：拷贝完好 .ibd + 对应 .frm（或 .isl），用 ALTER TABLE ... IMPORT TABLESPACE 导入——但这需严格匹配表结构和空间ID，非专业人士慎用。
