.frm文件是mysql表结构的元数据描述文件，与存储引擎无关；.ibd是innodb独立表空间文件，存数据和索引；.myd/.myi分别为myisam的数据和索引文件，三者需配套使用。
`.frm` 文件是表结构的唯一描述文件，与存储引擎无关
.frm 文件在所有 MySQL 存储引擎中都会生成，只要执行了 CREATE TABLE，就会在数据目录下产生对应表名的 .frm 文件。它保存的是字符集、行格式、字段定义、约束等元数据，不包含任何实际数据或索引逻辑。
常见错误现象：ERROR 1146 (42S02): Table 'db.t' doesn't exist 却能看见 t.frm 文件——说明表结构存在，但 InnoDB 的数据字典（ibdata1 或数据字典表）已丢失或未加载；MyISAM 则可能只是 .MYD/.MYI 损坏或缺失。
实操建议：
-
.frm是二进制格式，不能用文本编辑器直接读取；需用官方工具mysqlfrm解析（如：mysqlfrm --diagnostic /var/lib/mysql/db/t.frm） - MySQL 8.0+ 已弃用
.frm，改用数据字典表（mysql.ibd中的 SDI 页面），但降级迁移或恢复旧备份时仍会遇到.frm - 仅靠
.frm无法重建主键/外键约束的运行时状态，因为约束信息在 InnoDB 数据字典中维护，.frm仅存 DDL 声明快照
`ibd` 文件是 InnoDB 独立表空间的核心载体
.ibd 文件只在 innodb_file_per_table = ON（现代 MySQL 默认开启）时为每张 InnoDB 表单独生成，它同时承载数据记录和所有索引（聚簇索引 + 二级索引），体现 “索引即数据” 的本质。
关键区别：
- MyISAM 的
.MYD和.MYI是分离的：数据归数据，索引归索引，可单独损坏、单独修复 - InnoDB 的
.ibd是一体化的：删掉它等于删掉整张表的数据和索引；拷贝它必须配合同版本、同字符集、同ROW_FORMAT的.frm才可能导入 -
.ibd不含表结构定义——结构靠.frm（5.7 及以前）或数据字典（8.0+）提供；没有匹配的结构文件，.ibd就是一堆无法解释的页数据
MyISAM 的 .MYD 和 .MYI 文件可独立操作但耦合隐含
MyISAM 表必然生成三个文件：.frm（结构）、.MYD（数据）、.MYI（索引）。其中 .MYD 是纯行数据堆，.MYI 是 B-Tree 索引文件，二者通过文件内偏移地址关联。
容易踩的坑：
- 直接替换
.MYD而不更新.MYI→ 查询可能返回乱码或空结果，REPAIR TABLE可能失败 -
myisamchk -r修复.MYI时若跳过.MYD校验，可能重建出指向无效行偏移的索引节点 - 跨平台拷贝（如 Windows → Linux）要注意
.MYD文件末尾是否有多余换行或编码残留，可能被误判为损坏
恢复场景下 `.frm` + `.ibd` 组合不是“拿来就能用”
仅凭一对完好的 .frm 和 .ibd 文件，无法直接 CREATE TABLE 后 ALTER TABLE ... IMPORT TABLESPACE 成功——前提是 MySQL 实例必须处于严格一致的状态。
必要条件包括：
- 目标库的
innodb_file_per_table必须为ON，且未启用innodb_force_recovery -
.ibd对应的表在数据字典中不能已存在（否则报错Tablespace is not empty） - 必须先
CREATE TABLE得到结构一致的新表（字段顺序、类型、长度、索引定义完全相同），再DISCARD TABLESPACE，最后COPY并IMPORT - MySQL 5.7 中若
.frm与.ibd的SERVER_VERSION或CREATE_VERSION不匹配（如从 5.6 拷贝来），IMPORT会静默失败
最常被忽略的一点：InnoDB 表空间 ID（space_id）硬编码在 .ibd 文件头里，必须与数据字典中该表当前分配的 space_id 一致，否则即使所有步骤都对，也会卡在 “tablespace mismatch” 错误上。这个 ID 无法手动修改，只能靠 innodb_force_recovery=1 启动后用 SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES 查看，再决定是否重做导入流程。
