最近我在维护一套MySQL数据库时，数据库由于一个 InnoDB 表索引损坏，无法正常启动，只有在 innodb_force_recovery=6 模式下才能临时运行。尽管我已经成功导出了表结构和数据，但却陷入了一个死循环：不在恢复模式下，数据库无法启动；而在恢复模式下，我又无法 DROP 那张损坏的表。以下是我解决这个问题的全过程。
我在启动 MySQL 8.0 的时候收到如下错误日志：
Corruption of an index tree: table `db`.`file_content` index `create_time`...
[FATAL] You should dump + drop + reimport the table to fix the corruption...
数据库只能在配置文件中加入如下内容后才能启动：
[mysqld]
innodb_force_recovery = 6
在该模式下，我成功使用 mysqldump 导出了 file_content 表，并确认数据未报错。然而，在尝试执行 DROP TABLE file_content; 时，系统提示操作被禁止，因为 InnoDB 处于只读保护状态。
恢复步骤
第一步：确认并备份数据
我先使用以下命令导出数据：
mysqldump -u root -p db file_content > file_content.sql
这个步骤是关键，即使处于 innodb_force_recovery=6，mysqldump 通常仍然可以导出数据，除非数据页本身彻底损坏。
第二步：转储 binlog（可选）
为了最大程度减少数据丢失，我使用如下命令查看并导出 binlog：
mysqlbinlog --start-datetime="2025-06-06 05:00:00" --stop-datetime="2025-06-06 10:59:00" /var/log/mysql/mysql-bin.* > binlog_replay.sql
这一步可以在重新导入数据后，将最近的更新重放进表中。
第二阶段：清除损坏的表文件
由于 DROP TABLE 在恢复模式下无效，我采用物理方式直接删除表文件。
第三步：关闭 MySQL 服务
sudo systemctl stop mysql
第四步：删除表对应的 .ibd 文件
我进入 MySQL 的数据目录，找到损坏表所在的文件：
cd /var/lib/mysql/db
ls -l file_content.ibd
sudo rm -f file_content.ibd
第五步：编辑数据字典（危险，需小心）
如果使用了 innodb_file_per_table=ON，手动删除 .ibd 文件后，InnoDB 的数据字典中仍然认为该表存在，后续必须执行：
- 使用 innodb_force_recovery=6 启动。
- 尝试再次 DROP TABLE，此时表已无文件，InnoDB 会清理元数据。
- 关闭 innodb_force_recovery。
第六步：恢复表结构和数据
关闭 MySQL。
注释掉或移除配置文件中的 innodb_force_recovery=6。
重新启动 MySQL：
sudo systemctl start mysql
重新创建表并导入数据：
mysql -u root -p db < file_content.sql
如有 binlog，继续导入：
mysql -u root -p db < binlog_replay.sql
经验技巧
- innodb_force_recovery 是双刃剑：它允许你启动系统并导出数据，但几乎禁止任何写操作。
- 在无法删除损坏表的情况下，直接物理删除 .ibd 文件再用 DROP TABLE 清理字典是一种可行手段，但必须谨慎操作。
- 永远保留最近的全量备份与 binlog，这种突发事件时才不会完全失控。
- 在正式恢复之前，建议在另一台测试机或 Docker 环境中尝试一遍整个过程，确保操作不会破坏其他数据。
如果你也遇到类似 InnoDB 索引损坏的场景，希望这篇文章能为你提供清晰可行的解决路径。数据恢复的过程总是让人紧张，但只要操作得当，是可以稳妥处理的。
