MySQL损坏无法启动（innodb_force_recovery=6仍无效）及ibd文件恢复求助

我完全理解你现在的焦虑——卡了好几天，MySQL连innodb_force_recovery=6都救不回来，还得惦记着恢复ibd里的数据，这种困境太磨人了。先从你的日志里抓关键问题，再一步步给你可行的解决思路。

先分析日志里的核心错误 #

你日志里的致命问题是这条InnoDB断言失败：

2023-09-26T05:51:02.651234Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: fut0lst.ic:81:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA thread 4408

这说明InnoDB的底层链表结构已经严重损坏，普通的强制恢复参数已经没法绕过这种级别的错误了。不过咱们还是可以试试最后几个启动的可能性：

尝试最后让MySQL启动的方案 #

• 升级MySQL小版本：你现在用的是8.0.31，这个版本存在一些已知的InnoDB bug，建议临时升级到8.0系列的最新小版本（比如8.0.36），官方的bug修复可能直接解决这个断言失败的问题。
• 组合强制恢复参数：把innodb_force_recovery=6和以下参数一起加到my.ini/my.cnf里：

  innodb_read_only=1
  skip_innodb_doublewrite=1
  

  这些参数能让InnoDB跳过更多的损坏检查和写入操作，有可能让实例勉强启动（启动后只能读，绝对不能写）。如果能启动，立刻用mysqldump导出所有能访问的数据。

直接恢复ibd文件的正确步骤（针对你之前尝试失败的情况） #

你之前尝试新建实例替换ibd失败，大概率是表结构不匹配或者权限/配置没做好。ibd文件和表结构是强绑定的，差一点都不行，下面是标准的恢复流程：

1. 提取原表的精确结构
   如果没有原表的CREATE TABLE语句，用MySQL自带的ibd2sdi工具从ibd文件里提取：

   # 进入MySQL的bin目录执行
   ibd2sdi your_table.ibd
   

   这个命令会输出SDI（序列化字典信息），从中可以复制出精确到每个细节的CREATE TABLE语句（包括字符集、排序规则、ROW_FORMAT、索引定义等）。

2. 在新实例中创建完全一致的表
   用刚才提取的CREATE TABLE语句，在新MySQL实例里创建相同的数据库和表。注意：必须完全一致，哪怕是索引顺序、字段注释这种细节都不能错。

3. 解绑新表的ibd文件
   登录新实例，对要恢复的表执行：

   ALTER TABLE your_table_name DISCARD TABLESPACE;
   

   执行后，新表对应的ibd文件会被移除。

4. 复制原ibd文件并设置权限
   把原ibd文件复制到新实例对应数据库的目录下：

   • Windows：确保文件的所有者是Network Service（MySQL默认运行用户）
   • Linux：把文件权限改成mysql:mysql，执行chown mysql:mysql your_table.ibd

5. 导入表空间
   回到新实例的SQL终端，执行：

   ALTER TABLE your_table_name IMPORT TABLESPACE;
   

如果导入表空间失败的常见排查点 #

• 表结构不匹配：再仔细对比ibd2sdi输出的结构和你创建的表，比如ROW_FORMAT是Dynamic还是Compact，有没有遗漏的索引，字符集是否一致。
• ibd文件损坏严重：如果是这种情况，可以尝试用第三方工具（比如Percona Data Recovery Toolkit中的innodb_restore）来修复或提取数据，不过这类工具需要一定的操作经验。
• 配置问题：确认新实例的my.ini/my.cnf里开启了innodb_file_per_table=1（8.0默认是开启的，但还是检查一下）。

最后提醒 #

一旦成功恢复出数据，立刻全量备份！不要再在损坏的实例上浪费时间，先把数据捞出来是第一要务。之后一定要建立定期备份机制，比如用mysqldump做逻辑备份，或者用物理备份工具（如Percona XtraBackup），避免再遇到这种绝境。

备注：内容来源于stack exchange，提问作者Sunny Drall