即使innodb_file_per_table=ON，也不能直接拷贝.ibd文件，因.ibd依赖ibdata1中登记的表空间ID、索引根页等元数据；必须配合FLUSH TABLES FOR EXPORT生成.cfg、目标库建同构表并DISCARD后IMPORT，且需同步.ibd与.cfg、校验权限及space_id。
innodb_file_per_table=ON 也不等于能直接拷贝 .ibd
很多人看到 innodb_file_per_table=ON 就以为每张表的 .ibd 是“自包含”的，可以像 MyISAM 的 .myd 那样单独搬走。事实并非如此。即使启用了该参数，.ibd 文件仍依赖 ibdata1 中登记的元数据：表空间 ID、索引根页位置、加密密钥标识等。目标库的 ibdata1 里没有这条记录，MySQL 启动时就会报 Tablespace is missing for table 'db/tbl'。
FLUSH TABLES ... FOR EXPORT 不是导出命令，而是物理一致性快照
这个命令的作用常被误解。它实际做三件事：
- 强制刷写该表所有脏页到磁盘，确保
.ibd文件内容与内存一致 - 加读锁（阻塞 DML），冻结表状态
- 生成配套的
.cfg文件，含当前 LSN、页校验值、space_id 和加密上下文
漏掉这一步，哪怕 .ibd 文件完整，ALTER TABLE ... IMPORT TABLESPACE 也会失败，错误通常是 Failed to open the tablespace file 或 Incorrect information in file。
目标库必须先建同构空表，再 DISCARD TABLESPACE
不能跳过结构定义环节。目标库需执行：
-
CREATE TABLE，且引擎、ROW_FORMAT、KEY_BLOCK_SIZE、列顺序、字符集必须与源表完全一致（连注释差异都可能触发校验失败） -
ALTER TABLE tbl_name DISCARD TABLESPACE，删掉目标库已有的.ibd - 把源库的
.ibd和.cfg一起拷过去，属主设为mysql:mysql ALTER TABLE tbl_name IMPORT TABLESPACE
常见坑：.cfg 文件缺失、权限不对、ibdata1 中已有同名表但 space_id 冲突（此时需用 xtrabackup --export 重生成可移植表空间）。
跨实例迁移时 ib_logfile* 和 auto.cnf 很容易被忽略
如果尝试整库拷贝 datadir，只复制 ibdata1 + .ibd + .frm 是远远不够的：
-
ib_logfile0和ib_logfile1必须一并拷贝，且大小要和目标my.cnf中的innodb_log_file_size完全一致，否则 MySQL 直接拒绝启动 -
auto.cnf包含server-uuid，主从或 GTID 场景下缺失会导致复制初始化失败 -
mysql/目录下的系统表（如user.ibd）若与ibdata1元数据不匹配，会报Table 'mysql.user' doesn't exist
真正安全的物理迁移，几乎只能靠 xtrabackup --prepare 或 mysqlbackup 完成——它们不是简单复制文件，而是协调 redo log 回放、undo 截断、LSN 对齐、字典重建全过程。
