真损坏需依据错误日志关键词判断：lsn不匹配或事务子系统失败属假崩溃，可删日志重启；“database page corruption”、my-012562、my-013183或page number in space 0等才表明物理页或元数据真损坏，须谨慎启用innodb_force_recovery。
怎么看错误日志里是不是真损坏，而不是假崩溃？
错误日志开头几行决定你该不该动 innodb_force_recovery。别一看到 “InnoDB: Database page corruption” 就急着改配置——很多报错是“假损坏”，比如 ib_logfile* 和 ibdata1 的 LSN 不一致，本质只是崩溃后没走完恢复流程，删掉日志文件就能重启。
重点关注这些关键词（按严重程度从低到高）：
-
InnoDB: The log sequence number in ibdata1 does not match→ 日志和数据文件脱节，大概率只需删除ib_logfile0、ib_logfile1后重启 -
InnoDB: Failed to initialize transaction sub-system→ 事务子系统初始化失败，通常重建日志即可，不用进 recovery 模式 -
InnoDB: Database page corruption on disk或Corrupted page found→ 物理页损坏信号，需谨慎启用innodb_force_recovery -
InnoDB: Trying to access page number X in space Y, but space Y does not exist→ 空间 ID 不匹配，极可能是ibdata1被覆盖或误删，已属严重元数据损坏 -
MY-012562或MY-013183→ 官方定义的 InnoDB 崩溃错误码，基本确认是非正常关机或磁盘 I/O 异常导致的底层损坏
怎么从错误日志定位具体哪张表或哪个文件坏了？
MySQL 错误日志不会直接说“xxx.ibd 损坏了”，但会暴露路径线索。只要日志里出现带数据库名和表名的路径，基本就是问题源头：
- 看到类似
Tablespace is missing for table `test`.`user`→ 对应的test/user.ibd文件丢失或权限异常 - 出现
Operating system error number 2+ 表路径 → 文件系统层找不到该文件，先检查ls -l /var/lib/mysql/test/user.ibd - 报错含
page number 123456789 in space 0→space 0指系统表空间ibdata1，说明是全局性损坏，不是单表问题 - 错误中夹着
Table './db/table' is marked as crashed→ 这是 MyISAM 表标记损坏，和 InnoDB 无关，别碰innodb_force_recovery
更准的办法是启动成功后执行 SHOW ENGINE INNODB STATUS\G，看 LATEST DETECTED CORRUPTION 段落，它比错误日志更贴近实际损坏位置。
为什么不能跳过日志分析直接设 innodb_force_recovery = 6？
设错值或跳级尝试，会让本可读的表也变不可见。比如某次损坏只影响一个二级索引页，innodb_force_recovery = 1 就能绕过并导出全部数据；但若直接设为 4，InnoDB 会跳过缓冲池刷新、禁用所有写操作，连 DROP TABLE 都报 ERROR 1036 (HY000): Table is read only，而 SELECT 可能因索引未加载返回空结果。
更危险的是：级别 ≥ 5 会跳过日志前滚（log replay），可能导致导出的数据处于某个中间事务状态，逻辑上自相矛盾。生产环境几乎没人敢用 5 或 6，除非备份全丢且只剩这一条路。
实操铁律：
- 每次只调一级，从
innodb_force_recovery = 1开始 - 每调一级后必须完整 stop + start mysqld，不能 reload 配置
- 启动后立刻验证：
mysql -u root -p -e "SELECT COUNT(*) FROM mysql.user;"，能返回数字才算真正可用 - 一旦某级启动成功，就别再试更高值——越低越安全，越低导出越完整
导出数据时错误日志还在狂刷怎么办？
就算 innodb_force_recovery 让 MySQL 启动了，错误日志仍可能持续报错，比如反复刷 Failed to read page 或 Cannot find a valid checkpoint。这不是失败信号，而是 recovery 模式下 InnoDB 在尽力跳过坏页时留下的痕迹。
关键判断点只有一个：你能不能连上、能不能 SELECT 出预期数据。如果能，就立刻导出，别等日志安静下来——它可能永远不会停。
导出时务必加 --skip-lock-tables，否则 mysqldump 默认的 LOCK TABLES 会在 recovery 模式下卡死或报错；遇到某张表导不出，不要硬扛全库，改用 mysqldump -u root -p 库名 表名 > table.sql 单表导出。
最容易被忽略的一点：哪怕 innodb_force_recovery = 1 能查到 99% 的表，也不代表剩下 1% 的页没损坏。那些页可能藏在索引深处、undo 段里，导出时不会立即暴露，但导入新实例后可能引发二次崩溃。所以导出后必须重建，不能复用旧 ibdata1。
