innodb_force_recovery是只读逃生通道，非修复开关；设错值或跳级尝试可能导致可读表不可见，须依错误日志关键词（如“database page corruption”）确认真损坏，并严格从级别1逐级尝试、配合--skip-lock-tables导出数据后重建实例。
别直接设 innodb_force_recovery = 6，它不是修复开关，而是“抢数据”的只读逃生通道；设错值或跳着试，可能让还能读的表也变不可见。
怎么看真是InnoDB损坏，而不是假崩溃？
先打开错误日志（Linux 在 /var/log/mysql/error.log，Windows 在 mysql\data\hostname.err），翻到最开头几行，盯住这些关键词：
-
InnoDB: Database page corruption on disk→ 真损坏嫌疑高 -
InnoDB: The log sequence number in ibdata1 does not match→ redo log 和数据文件 LSN 不一致，常见于强制 kill 后重启 -
InnoDB: Failed to initialize transaction sub-system→ 往往只需重建日志，不用开 recovery 模式 -
Unable to lock ./ibdata1→ 更可能是残留进程或权限问题，不是数据损坏
如果日志里夹着 Table 'xxx' is marked as crashed，那基本是 MyISAM 表坏了，走 mysqlcheck --repair，别碰 innodb_force_recovery。
怎么安全设置 innodb_force_recovery？
这个参数必须写进 my.cnf（Linux）或 my.ini（Windows phpEnv），且只在 [mysqld] 段下生效。不能动态改，也不能靠面板点“重启”就加载。
- Linux：改完配置后，先
sudo mysqladmin shutdown，再sudo systemctl start mysql - Windows phpEnv：必须用命令行停服务：
net stop mysql，再net start mysql；若失败，进mysql\bin\直接运行：mysqld --defaults-file=..\my.ini --console看实时日志 - 每次只加 1 级：从
innodb_force_recovery = 1开始，启动失败再试 2、3……不要跳着设 - 值 ≥ 4 后，所有写操作（包括
DROP TABLE）都会报ERROR 1036 (HY000): Table is read only，SELECT 也可能因跳过索引构建而失败
导出数据时必须绕开的坑
就算 innodb_force_recovery = 3 成功启动，mysqldump 仍大概率中途卡死或漏表——因为默认行为会触发 LOCK TABLES，而 recovery 模式下锁机制异常。
- 必须加
--skip-lock-tables，否则 dump 会等锁、超时、断连 - 加
--single-transaction可降低一致性压力，但仅对支持事务的引擎有效 - 遇到某张表导不出，立刻切到单库导出：
mysqldump -u root -p 库名 > db.sql，别硬扛全库 - 若
mysqldump报Lost connection to MySQL server，换SELECT ... INTO OUTFILE或用mysqlpump（MySQL 5.7+）
导完数据后最关键的一步
哪怕 innodb_force_recovery = 6 都能连上并导出全部 SQL，也绝不能删掉这行配置、直接重启继续用——此时 InnoDB 内部结构已不一致，再次启动极大概率二次崩溃，且可能永久丢失 undo 日志或字典信息。
正确做法是：停掉 MySQL，备份好当前全部 ibdata1、ib_logfile*、*.ibd 文件（哪怕损坏也留着），然后用导出的 .sql 文件重建全新实例。ibdata1 不匹配、版本混用、8.0 数据字典损坏等情况，没有“在线修复”，只有重建。
