不能直接修复损坏的.ibd文件，但可通过ibd2sql跳过坏页提取可用数据，或手动修正space_id后尝试IMPORT；关键需匹配MySQL版本、确保文件未被占用、预留足够磁盘空间。
不能直接“修复”损坏的 .ibd 文件，但能提取尚可读的数据——关键在于跳过坏页、对齐 space_id、绕过 InnoDB 启动依赖。
为什么 ALTER TABLE ... IMPORT TABLESPACE 会报 ERROR 1808 或校验失败
这类错误说明 .ibd 文件内部页结构已损坏（如 page checksum 不通过、fil_header 被覆写、user record 区域大量 0xff），InnoDB 在加载时主动拒绝。此时标准导入流程失效，不是权限或路径问题，而是页级数据不可信。
常见误操作包括：
- 未停库就拷贝正在使用的
.ibd文件，导致读到 stale cache 或空页 - 直接把旧库的
.ibd拷进新实例，space_id不匹配（查法：SELECT space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE name='db/t1'） - 用 MySQL 5.7 的
mysqlfrm解析 MySQL 8.0 的.ibd，解析出错或字段数对不上
用 ibd2sql 离线提取最大可用数据（MySQL 8.0 必须）
ibd2sql 不依赖 mysqld 运行，逐页扫描 + try/except 跳过坏块，适合 mysqld 已无法启动、ibdata1 损坏、甚至 .frm 丢失的场景。
运行前必须确认三件事：
-
mysql --version输出为8.0.x（工具硬编码了 8.0 的页结构偏移，5.7 的.ibd会解析错） -
.ibd文件未被任何进程占用（从只读快照或停库后拷贝） - 磁盘剩余空间 ≥ 原
.ibd体积 × 2.5（含大文本/JSON 字段时膨胀明显）
基础命令：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
python3 main.py /path/to/db/t1.ibd --sql --complete-insert --mysql8
加 --ddl 可同时输出 CREATE TABLE，但注意：该 DDL 不含外键、注释、分区、压缩属性，仅字段与索引定义。
手动修正 space_id 并走 IMPORT 流程（需表结构已知）
当 ibd2sql 提取结果为空或乱码严重，且你**确认表结构**时，可尝试标准导入——但必须修正 space_id。
步骤要点：
- 在目标库建同名空表：
CREATE TABLE t1 (...) ENGINE=InnoDB - 执行
ALTER TABLE t1 DISCARD TABLESPACE清空其.ibd - 用
xxd -r或hexedit修改原.ibd文件偏移0x38处的 4 字节，设为当前表的space值（单位：十进制转小端十六进制） - 拷贝修正后的
.ibd到对应数据库目录，chown mysql:mysql - 导入前执行
SET FOREIGN_KEY_CHECKS=0，再ALTER TABLE t1 IMPORT TABLESPACE
若仍报页校验失败，说明 user record 区域损坏严重，此时应放弃此路径，退回 ibd2sql 提取。
最易被忽略的物理细节
真正难的不是命令怎么敲，而是判断哪些页还能读、哪些必须跳过。InnoDB 页格式复杂，ibd2sql 的“跳过坏块”是按页粒度做的，如果损坏集中在 page directory 或 index header，它可能仍吐出大量有效记录；但如果 user record 区域被批量覆写为 0xff 或加密页（ROW_FORMAT=ENCRYPTED）、压缩页（ROW_FORMAT=COMPRESSED）、非默认 innodb_page_size，结果就是空或极少量输出——这些限制不会报错，只会静默跳过。
