innodb_force_recovery不是修复工具，而是通过逐级跳过崩溃恢复步骤（如忽略损坏页、禁purge、跳回滚、停redo前滚）实现只读启动以抢救数据，必须从1开始逐级尝试，级别越高逻辑损坏风险越大。
MySQL 5.7 在非正常关机后无法自动崩溃恢复，根本原因不是“没做恢复”，而是恢复流程本身被损坏的数据结构卡死了——InnoDB 启动时必须校验并重放 ibdata1 和重做日志（ib_logfile0/1），一旦这些文件中关键页（如系统表空间 page 0、事务系统页、undo log 页）损坏或校验失败，整个恢复链就中断，直接报错退出。
innodb_force_recovery 不是修复，而是绕过校验
当错误日志出现类似 [ERROR] InnoDB: Database page corruption on disk 或 [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace，说明 InnoDB 已经检测到不可跳过的损坏。此时它不会尝试“智能修复”，而是拒绝启动以防止进一步写入污染。
-
innodb_force_recovery=1只是让 InnoDB 忽略部分页校验，并跳过某些后台操作（如 purge、buffer pool load），但不修复任何东西 - 值设为 4 或更高时，InnoDB 甚至会放弃读取 undo log、跳过回滚，把未提交事务当作已提交——这会导致数据逻辑不一致，仅用于抢救性导出
- 所有大于 0 的值都会禁用
INSERT/UPDATE/DELETE，只允许SELECT、DROP、CREATE，这是硬性限制，不是配置遗漏
为什么不能像操作系统那样“自动 fsck”？
InnoDB 的恢复机制依赖于完整的 WAL（Write-Ahead Logging）链条：redo log → undo log → 数据页。非正常关机可能造成：
- redo log 写了一半（
ib_logfile0半截损坏），无法前滚 - undo log 页被刷到磁盘但 header 损坏，InnoDB 无法定位活跃事务
-
ibdata1中的 SYS_TABLES、SYS_INDEXES 等核心字典页损坏，连表结构都读不出来
这些都不是“校验和错误”能简单跳过的层级问题，而是元数据断裂。MySQL 没有内置的页级重建能力，也没有类似 fsck 的离线修复工具。
常见误操作会让情况更糟
很多人看到启动失败，第一反应是删 ib_logfile* 或执行 mysqld --initialize-insecure，结果反而丢掉还能抢救的业务表文件（.ibd）：
- 直接删除
ib_logfile*并重启：InnoDB 会尝试重建日志，但若ibdata1已损坏，仍会失败；且丢失未刷盘的 redo，可能让部分已提交事务丢失 - 运行
mysqld --initialize-insecure：会清空整个datadir，包括你还没导出的.ibd和.frm文件，彻底断绝抢救路径 - 在
innodb_force_recovery > 0状态下执行ALTER TABLE ... IMPORT TABLESPACE：该命令需要完整 undo 和字典信息，强制模式下大概率报错Tablespace is missing for table
真正能抢救数据的窗口非常窄：只有在 innodb_force_recovery 让 MySQL 勉强启动后，立刻用 mysqldump 导出，且导出过程中不能触发任何涉及损坏页的操作（比如 dump 某个已损坏的表会卡住）。一旦导出完成，就必须立即停服务、注释该参数——多运行一分钟，都可能因查询触发新损坏而失去最后机会。
