直接拷贝ibd文件常失败，因需满足：innodb_file_per_table=ON；源库执行FLUSH TABLES...FOR EXPORT生成.cfg；目标库先建同构表、DISCARD TABLESPACE；.ibd与.cfg须一同拷贝且权限正确。
直接拷贝 ibd 文件为什么常失败
不是所有 InnoDB 表都能单独拷贝 .ibd 文件。默认情况下，MySQL 启用 innodb_file_per_table=ON 时，每张表才生成独立的 .ibd 文件；若为 OFF，所有表数据都挤在共享表空间 ibdata1 里，此时只拷 .ibd 会缺失元数据和事务上下文，导入必报错 Tablespace is missing for table xxx 或 Incorrect information in file: './db/t.frm'。
即使 ON，也必须满足：源库已执行 FLUSH TABLES tbl_name FOR EXPORT（冻结表、刷脏页、生成 .cfg 元数据文件），目标库要先 CREATE TABLE 结构一致，再 DISCARD TABLESPACE，最后 IMPORT TABLESPACE。漏掉任意一步，ALTER TABLE ... IMPORT TABLESPACE 就会卡住或报错 Failed to open the tablespace file。
FLUSH TABLES ... FOR EXPORT 的真实作用
这个命令不是“导出”，而是为物理拷贝做一致性快照：它强制刷写缓冲池中该表的所有脏页到磁盘，禁用对该表的 DML，同时生成一个 .cfg 文件（含表空间加密密钥、页校验信息、当前 LSN）。没有它，拷过去的 .ibd 可能处于中间状态，IMPORT 时 MySQL 会拒绝加载。
- 必须在源库以
root或有LOCK TABLES权限的用户执行 - 仅对单表或逗号分隔的多表生效，不支持
FOR EXPORT全库 - 执行后表仍可读（SELECT），但写入（INSERT/UPDATE/DELETE）会被阻塞，直到
UNLOCK TABLES -
.cfg文件必须和.ibd一起拷贝，少一个就IMPORT失败
目标库 IMPORT TABLESPACE 前必须做的三件事
跳过任何一项，ALTER TABLE t IMPORT TABLESPACE 都会静默失败或报错 Table has no partition function but a partition handler is present 这类误导性信息。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 目标库必须已存在同名数据库和结构完全一致的表（字段顺序、类型、索引、外键、字符集、ROW_FORMAT 都要相同）
- 执行
ALTER TABLE t DISCARD TABLESPACE—— 这步是释放目标表当前的表空间引用，否则无法替换 - 确保
.ibd和.cfg文件权限为mysql:mysql，且放在目标库datadir/dbname/下（路径不能错）
注意：IMPORT 不会校验数据逻辑一致性，只检查物理页结构和 LSN 连续性。如果源库崩溃过或 .ibd 损坏，导入后可能查不到数据但无报错。
比单表拷贝更稳妥的替代方案：Percona XtraBackup
当你要迁移整个库、或包含大量分区表、或不能接受 FLUSH TABLES FOR EXPORT 引起的短暂写阻塞时，mysqldump 太慢，cp /var/lib/mysql/dbname 又太危险 —— 这时候 xtrabackup 是唯一兼顾热备与物理一致性的选择。
它通过读取 ib_logfile 和 ibdata1 实时捕获变更，最终生成带完整恢复点的备份包。还原时只需 xtrabackup --prepare + cp -r 到目标 datadir，改权限，启动 mysqld。整个过程不依赖 FLUSH TABLES，也不要求 innodb_file_per_table 开关一致。
容易被忽略的是：xtrabackup 备份出来的数据目录，不能直接 mv 进正在运行的 MySQL datadir —— 必须先停掉目标 mysqld，清空原 datadir，再复制，否则启动失败率极高。
