不能安全实现。直接拷贝 ibdata1 和 .frm 文件无法完成可用的物理迁移，缺失 .ibd、事务日志、系统表空间一致性校验等关键组件，启动时大概率报错或数据不可见。
不能安全实现。直接拷贝 ibdata1 和 .frm 文件无法完成可用的物理迁移，缺失 .ibd、事务日志、系统表空间一致性校验等关键组件，启动时大概率报错或数据不可见。
为什么只拷 ibdata1 + .frm 一定失败
这是因为 ibdata1 并不“存数据”，它只存全局元数据（如数据字典、undo logs、change buffer）和共享表空间中的表数据——而绝大多数业务表都启用了 innodb_file_per_table=ON，真实数据全在各自的 .ibd 文件里。只拷 ibdata1 和 .frm，等于只搬了目录和图纸，没搬房子本身。
常见错误现象包括：
-
Tablespace is missing for table 'db/tbl'：InnoDB 启动时发现ibdata1里登记了某张表，但对应db/tbl.ibd不存在或路径不对 -
InnoDB: Database page corruption on disk：ibdata1的 checkpoint LSN 与缺失的日志文件不匹配，崩溃恢复失败 - 表能 SHOW，但 SELECT 报错
ERROR 2013 (HY000)或直接返回空结果：结构加载了，但数据页根本没连上
ibdata1 必须和哪些文件一起拷贝才可能启动
若坚持停机拷贝（非推荐路径），必须整套同步以下内容，缺一不可：
-
ibdata1（系统表空间，含数据字典） - 所有数据库子目录（如
myapp/）及其全部.ibd、.frm（MySQL 5.7 及更早）、.sdi（8.0+）文件 -
ib_logfile0和ib_logfile1（重做日志，LSN 对齐必需） -
mysql/目录（含权限表、系统视图定义等） -
performance_schema/、sys/（部分版本启动时校验存在性） -
auto.cnf（server UUID，主从或 GTID 场景下影响复制初始化）
注意：ib_logfile* 大小必须与目标 my.cnf 中 innodb_log_file_size 完全一致，否则启动直接拒绝——这是跨服务器迁移最常踩的坑之一。
想单表恢复？别碰 ibdata1，用 DISCARD TABLESPACE + IMPORT TABLESPACE
如果只是补一张表，且你有该表完整的 .ibd 和 .frm（或 .sdi），可以绕过 ibdata1 全局操作：
- 先在目标库建同名同结构的空表（引擎、
ROW_FORMAT、KEY_BLOCK_SIZE必须完全一致） - 执行
ALTER TABLE tbl_name DISCARD TABLESPACE，删掉当前tbl_name.ibd - 把备份的
.ibd文件拷到对应数据库目录，属主改为mysql:mysql - 执行
ALTER TABLE tbl_name IMPORT TABLESPACE
但注意：该操作要求源表 .ibd 的 space_id 与目标实例当前分配的 id 不冲突；若冲突，需用 xtrabackup --export 生成可移植表空间，或改用 mysqldump 逻辑导出。
真正能用的物理迁移，只依赖两个工具
生产环境唯一被验证可靠的物理迁移方式，是使用专为 InnoDB 设计的一致性快照工具：
-
percona-xtrabackup（开源，支持 5.7 / 8.0，主流 Linux 发行版仓库自带） -
mysqlbackup（MySQL Enterprise Backup，仅限企业版许可）
它们的工作不是“复制文件”，而是：
- 暂停 checkpoint，记录精确 LSN 位点
- 拷贝所有数据文件 + 日志 + 系统表空间
- 通过
--prepare做前滚/回滚，使文件达到“可直接挂载”状态 - 自动处理
ibdata1与每个.ibd的 space_id / LSN 对齐
跳过这一步，任何手动拼凑 ibdata1、.frm、.ibd 的尝试，本质上都是在赌运气——而数据库不接受赌注。
