mysqlfrm工具可离线解析5.6/5.7的.frm文件生成create table语句，需匹配mysql版本；无.frm时可用.ibd结合import tablespace恢复，但须结构完全一致且先建空表注册元数据。
mysqlfrm 工具解析 .frm 文件生成 CREATE TABLE 语句
如果你手头只有 .frm 文件（不含 ibdata1 或运行中的 MySQL 实例），mysqlfrm 是最直接可用的官方工具。它不依赖 MySQL 服务，纯离线解析二进制结构。
常见错误现象：mysqlfrm 报错 “Unsupported file format” 或直接退出 —— 多因 MySQL 版本不匹配。MySQL 5.7 的 .frm 和 8.0+ 的结构不兼容，8.0 默认已移除 .frm（改用数据字典表），所以该方法仅适用于 5.6/5.7 及更早版本。
- 确认 MySQL 版本：执行
mysqld --version，若为 8.0+，则.frm文件大概率不存在或为空，跳过此步 - 安装对应版本的 MySQL Utilities（如 5.7 配套的
mysql-utilities-1.6.5） - 运行命令：
mysqlfrm --diagnostic /path/to/table.frm --server=none，输出即为可执行的CREATE TABLE语句 - 注意字符集与引擎：输出语句中可能缺省
CHARACTER SET或ROW_FORMAT，需结合应用日志或原库SHOW CREATE TABLE记录补全
从 .ibd 文件反推表结构（无 .frm 时的兜底方案）
.ibd 文件本身不存字段名、类型等元数据，但 InnoDB 数据页头部含部分结构线索（如主键长度、字段数、行格式）。真正可行的“反推”，其实是靠经验 + 限制条件组合还原。
使用场景：仅剩 .ibd，且无任何备份、日志、代码参考 —— 此时只能尝试构造“结构合理”的表，再通过 IMPORT TABLESPACE 碰撞验证。
- 必须已知或能合理假设：主键字段名及类型（否则
IMPORT必失败）、字段总数、是否含大字段（TEXT/BLOB）、ROW_FORMAT（compact/dynamic/compressed） - 查
ROW_FORMAT：用hexdump -C table.ibd | head -20查前几 KB，搜索字符串COMPACT或DYNAMIC（不绝对，但有高概率） - 建表时务必加
ENGINE=InnoDB ROW_FORMAT=xxx，否则ALTER TABLE ... IMPORT TABLESPACE会报错Tablespace is not encrypted but encryption flag is set或直接崩溃 - 导入失败后不要反复重试：每次
IMPORT失败都可能导致 MySQL 进程异常终止，先查error log中最后一段警告，重点关注InnoDB: Operating system error number和page corruption
用 CREATE TABLE + DISCARD/IMPORT 恢复数据（结构已知前提下）
这是唯一能绕过 ibdata1 丢失、且稳定恢复数据的操作路径。核心不是“读取 .ibd”，而是让 MySQL 相信这张表的物理存储就是你给的文件。
容易踩的坑：权限、路径、状态不一致。哪怕表结构一字不差，一个 chown 漏掉或 DISCARD 后没停服务就拷文件，都会导致 IMPORT 报错 Tablespace mismatch。
- 建表语句必须与原始表完全一致：包括字段顺序、默认值、
NOT NULL、索引定义（尤其是主键）、COMMENT（某些版本校验注释） - 执行
ALTER TABLE table_name DISCARD TABLESPACE前，确保表无活跃事务，且innodb_file_per_table=ON（MySQL 5.6+ 默认开启） - 拷贝
.ibd文件后，必须执行：chown mysql:mysql /var/lib/mysql/db_name/table_name.ibd（Docker 环境需进入容器操作） -
ALTER TABLE table_name IMPORT TABLESPACE成功后，立即执行SELECT COUNT(*) FROM table_name验证；若返回 0 或报错，说明结构不匹配，别继续插入，先查SHOW WARNINGS
为什么不能直接复制 .ibd 到 data 目录然后重启？
因为 InnoDB 不像 MyISAM 那样靠文件名绑定表。它的元数据（表名→空间ID映射、列偏移、索引根页位置）全存在 ibdata1 或数据字典中。直接放文件进去，MySQL 启动时发现字典里没有这个表，就会忽略它；或者发现 ID 冲突，直接拒绝启动。
这也是所有恢复流程都强制要求“先建同名空表”的根本原因：建表动作会在数据字典中注册该表的元数据，DISCARD 清空其逻辑空间，IMPORT 才能把你的 .ibd 文件内容“挂载”到已注册的元数据节点上。
真正复杂的地方在于：一旦原始 ibdata1 损毁或缺失，你就永远无法 100% 还原外键约束、全文索引配置、分区定义这些高级元数据 —— 它们只存于全局表空间，.ibd 里不带这些信息。
