因为innodb不信任裸拷贝的.ibd文件，必须通过flush tables t for export生成配套.cfg文件才能导入；漏掉该步骤会导致import tablespace静默挂起或报tablespace is missing for table。
为什么直接 cp .ibd 会卡在 ALTER TABLE ... IMPORT TABLESPACE？
因为 InnoDB 不信任裸拷贝的 .ibd 文件——它只认自己生成的元数据快照。漏掉 FLUSH TABLES t FOR EXPORT，就不会产生配套的 t.cfg，IMPORT TABLESPACE 就会静默挂起或报 Tablespace is missing for table。这不是权限或路径问题，是校验机制强制要求：没有 .cfg，InnoDB 连文件头都不读。
FLUSH TABLES ... FOR EXPORT 必须立刻配 UNLOCK TABLES
这条命令会让表进入只读+导出准备状态，但它不自动释放锁。如果你执行完就去查 SHOW PROCESSLIST 或等几秒再拷文件，很可能已有其他事务写入，导致 .cfg 和 .ibd 的 LSN 不一致，导入后查不到数据却无报错。
- 必须在
FLUSH TABLES t FOR EXPORT后**立刻**执行cp /var/lib/mysql/db/t.{ibd,cfg} /backup/ - 紧接着马上执行
UNLOCK TABLES（不是FLUSH TABLES） - 检查
.cfg是否非空：stat /backup/t.cfg && head -c 20 /backup/t.cfg；空文件说明导出失败，常见于表正被ALTER或处于崩溃恢复中
目标库建表和 DISCARD TABLESPACE 的硬性对齐点
结构“一致”不是指字段名和类型看起来一样，而是包括：CHARSET、COLLATE、ROW_FORMAT（尤其是 COMPRESSED）、PAGE_COMPRESSED、索引顺序、外键定义（哪怕禁用了也要存在）、甚至 STATS_PERSISTENT 设置。任意一项不匹配，IMPORT TABLESPACE 可能成功返回但后续 SELECT 报错或返回空结果。
- 用
SHOW CREATE TABLE导出建表语句，**不要手动改写**；MySQL 8.0.23+ 要注意JSON字段是否带STORED属性 -
DISCARD TABLESPACE前必须关闭外键检查：SET FOREIGN_KEY_CHECKS=0，否则报错 - 确保目标库
datadir下对应库目录存在，且.ibd和.cfg都放进该目录，权限为mysql:mysql
归档场景下比 mysqldump 快，但比想象中更脆
千万级单表用表空间传输，耗时通常控制在分钟级（取决于磁盘 I/O），而 mysqldump + mysql 可能数小时。但它的脆弱点藏在细节里：源库和目标库的 innodb_page_size 必须完全一致；如果归档到低版本 MySQL（如从 8.0.33 到 5.7），即使满足所有条件也会失败；分区表、全文索引、加密表都默认不支持——这些限制不会在 FLUSH 或 IMPORT 时报错，而是在后续查询时才暴露。
