直接复制.ibd+.frm报“tablespace is missing”是因为innodb元数据（如space_id、根页地址）存于ibdata1而非.ibd中，目标库缺失字典记录；需flush tables for export生成.cfg校验文件，并配合discard/import流程才能安全迁移。
因为 InnoDB 的表元数据不全在 .ibd 文件里，核心信息（如表空间 ID、索引根页位置、加密上下文）登记在共享的 ibdata1 中；目标库没有对应记录，MySQL 启动时直接报 Tablespace is missing for table。
为什么直接复制 .ibd + .frm 会报 “Tablespace is missing”
MyISAM 的 .myd 和 .myi 是自包含的，拷过去改权限就能用；InnoDB 的 .ibd 却像一张“没登记户口的身份证”——它依赖 ibdata1 里的字典条目才能被识别。即使 innodb_file_per_table=ON，也只表示数据物理分离，不代表元数据独立。
-
ibdata1里存着该表的space_id、主键 B+ 树根页地址、外键约束引用关系等，缺失即不可用 -
.frm（或 MySQL 8.0+ 的.sdi）只存列定义和索引名，不存存储层元数据 - 目标库启动时扫描
ibdata1，发现没这条记录，就跳过.ibd，不加载也不报错，直到你SELECT才触发Tablespace is missing
FLUSH TABLES ... FOR EXPORT 到底在做什么
这不是导出命令，而是为物理拷贝做一致性快照：它让 InnoDB 把这张表当前所有脏页刷到磁盘、加读锁防止写入、并生成一个配套的 .cfg 文件——里面含 space_id、校验值、LSN、加密密钥标识等关键元数据。
- 必须在拷
.ibd前执行，且.cfg和.ibd必须一起拷，缺一不可 - 执行后表仍可
SELECT，但INSERT/UPDATE/DELETE会被阻塞，直到你显式UNLOCK TABLES - 如果
.cfg是空文件，说明导出失败，常见于表正被ALTER或处于崩溃恢复中
目标库 IMPORT TABLESPACE 失败的三个硬性前提
哪怕 .ibd 和 .cfg 都对，只要以下任一条件不满足，ALTER TABLE ... IMPORT TABLESPACE 就会静默失败或报错（比如 Incorrect key file for table）。
- 目标库必须已存在同名数据库，并用完全一致的
CREATE TABLE语句建好空表（字段顺序、类型、字符集、ROW_FORMAT、KEY_BLOCK_SIZE、注释都得一样） - 必须先执行
ALTER TABLE t DISCARD TABLESPACE，否则旧表空间引用还在，新文件进不来 -
.ibd和.cfg文件权限必须是mysql:mysql，且必须放在datadir/dbname/下，路径错一点都不行
真正容易被忽略的是：跨版本迁移时，.cfg 文件里带的 LSN 和页格式可能不被目标 MySQL 版本识别（例如从 5.7 导出的 .ibd + .cfg，在 8.0.22 以下版本无法导入），这时只能换 xtrabackup --export 重生成。
