恢复前必须停库并确认文件权限，否则99%失败；需用错误日志反推字段数重建结构，再通过DISCARD/IMPORT TABLESPACE安全挂载.ibd文件。
恢复前必须停库并确认文件权限
不关 MySQL 服务就直接替换 .frm 或 .ibd 文件，99% 会失败甚至损坏文件。MySQL 进程锁住数据目录，强行覆盖会导致文件句柄错乱或元数据不一致。你得先执行 net stop mysql（Windows）或 systemctl stop mysqld（Linux），确保进程彻底退出。
替换后要检查文件属主和权限：Linux 下 .frm 和 .ibd 文件必须属于 mysql:mysql 用户组，权限设为 660；Windows 下需确认 MySQL 服务账户有读写权限。我见过三次恢复失败，都是因为 .frm 文件属主是 root，MySQL 启动时静默跳过加载，日志里只有一行 [Warning] InnoDB: Ignoring table ...，根本没报错。
用错误日志反推字段数量来重建表结构
别指望直接读 .frm 文件——它是二进制格式，MySQL 5.7 没提供官方解析工具。正确做法是：在同名数据库下先建一张字段数随意的同名空表（比如 CREATE TABLE orders (id INT)），停库后用备份的 orders.frm 覆盖它，再启库。这时 DESC orders 会失败，但 MySQL 错误日志（hostname.err）里一定有类似这样的提示：InnoDB: Table db/orders contains 1 user defined columns in InnoDB, but 7 columns in MySQL。
- 这个 “7” 就是原表真实字段数，不是猜测值，必须严格对齐
- 字段名和类型可以先随便填（如
col1 VARCHAR(255), col2 INT），只要总数对就行 - 建完新表后再次覆盖
.frm，再启库，SHOW CREATE TABLE orders就能拿到完整 DDL 了
IMPORT TABLESPACE 前必须先 DISCARD
光有结构还不够，.ibd 文件不能直接扔进目录就生效。InnoDB 表空间有内部一致性校验，必须走标准流程：
先连上 MySQL，执行 ALTER TABLE orders DISCARD TABLESPACE; —— 这会删掉当前表的 .ibd 文件（只是逻辑删除，磁盘上没真删）；然后停库，把备份的 orders.ibd 放到对应目录；最后启库，再执行 ALTER TABLE orders IMPORT TABLESPACE;。
注意两点：
- IMPORT TABLESPACE 要求 .ibd 文件的 space_id 必须和表定义匹配，如果之前建表时引擎不是 InnoDB，或者用了 CREATE TABLE ... ENGINE=MyISAM，这步会卡住并报错 Tablespace mismatch
- 执行 IMPORT 后，表里数据可查，但 TABLE_ROWS 在 information_schema.TABLES 里可能显示为 0，这是正常现象，不影响实际读写
为什么不用 mysqlfrm 工具？
mysqlfrm 是 MySQL Utilities 里的一个工具，理论上能直接解析 .frm 输出建表语句。但它在 MySQL 5.7 后基本失效：一是官方已停止维护该套件，二是它依赖 Python 2 环境，且对新版 .frm 格式兼容性差。我试过 5.7.44 版本下用 mysqlfrm --server=root@localhost:3306 --diagnostic /path/to/table.frm，结果要么报 Unsupported .frm file version，要么输出的字段类型全变成 TEXT，完全不可信。
所以实操中更可靠的方式，还是靠错误日志反推字段数 + 手动补全 DDL。复杂点在于字段类型和约束（比如 NOT NULL、默认值、索引），这些信息确实无法从 .frm 里直接提取，只能结合业务逻辑、历史 SQL 记录或应用代码去还原——这才是真正容易被忽略的硬骨头。
