tb级mysql跨服务器离线迁移唯一可行方案是innodb可传输表空间机制，需严格按flush tables ... for export→复制.ibd与.cfg→目标库discard/import tablespace流程执行，缺一不可。
TB级MySQL数据库跨服务器离线迁移，不能靠mysqldump硬扛，也不该直接拷贝.ibd文件了事——前者会卡死、超时、内存溢出；后者在MySQL 8.0+上大概率报错Tablespace mismatch或Invalid tablespace。真正可行的路径只有一条：用InnoDB可传输表空间（Transportable Tablespace）机制，配合FLUSH TABLES ... FOR EXPORT和DISCARD/IMPORT TABLESPACE组合操作。
为什么直接复制.ibd在MySQL 8.0上会失败
MySQL 5.7起引入了数据字典（Data Dictionary）强绑定机制，每个.ibd文件内嵌一个唯一的tablespace_id，而目标库的元数据里记录的是它自己生成的ID。直接复制过去，MySQL启动时发现ID不匹配，直接拒绝加载，报错类似：Tablespace is missing for table 'db.t1'或InnoDB: Error: tablespace id in file ./db/t1.ibd is 123, but in data dictionary it is 456。
关键点在于：.cfg文件不是可选附件，而是校验凭证——它由FLUSH TABLES ... FOR EXPORT生成，包含源库当时的tablespace_id、页校验和、schema指纹等，是目标库做IMPORT TABLESPACE时唯一信任的“身份证”。
- 没
.cfg→IMPORT TABLESPACE必然失败 -
.cfg过期（比如源表后续被ALTER过）→ 校验失败，报Invalid or missing .cfg file - 目标库未执行
DISCARD TABLESPACE就放文件 → MySQL忽略.ibd，仍用空表结构
FLUSH TABLES ... FOR EXPORT必须在源库执行且保持锁态
这个命令不是“导出快照”，而是冻结表状态并刷新脏页到磁盘，同时让表进入只读锁定（其他事务写入会被阻塞）。你必须在锁住期间完成.ibd和.cfg的复制，否则一旦锁释放，.ibd可能被修改，.cfg就失效了。
实操要点：
- 执行前确认
innodb_file_per_table = ON（否则没有独立.ibd） - 不要用
SELECT ... INTO OUTFILE替代——它不生成.cfg，也不保证一致性 - 复制命令建议用
rsync -av --progress而非cp，避免中断重来 - 锁住后立刻查
SHOW VARIABLES LIKE 'datadir';定位真实路径，别依赖mysql -e "SELECT @@datadir"返回值（可能有符号链接）
目标库DISCARD/IMPORT TABLESPACE流程不能跳步
目标库必须先建好结构完全一致的空表（字段顺序、类型、索引、外键约束、字符集、排序规则都得一模一样），再走三步：
-
ALTER TABLE db.t1 DISCARD TABLESPACE;—— 删除空.ibd，进入“等待导入”状态 - 把源库的
t1.ibd和t1.cfg放到目标库对应目录（如/var/lib/mysql/db/t1.ibd），属主改为mysql:mysql -
ALTER TABLE db.t1 IMPORT TABLESPACE;—— 此时才真正校验并挂载
常见坑：
- 目标表
CREATE TABLE语句里漏了ENGINE=InnoDB→ 默认变成MyISAM，DISCARD报错 - 源表用了
ROW_FORMAT=COMPRESSED但目标库innodb_file_format未启用 →IMPORT失败 - 复制时
.cfg权限为600（默认），但目标MySQL进程无法读取 → 改成644 - 表有全文索引（
FULLTEXT）→ MySQL 8.0.23+才支持IMPORT，旧版本需先删索引再重建
TB级表拆分迁移与并发控制的实际约束
单表几亿行？别幻想一次FLUSH搞定。锁表时间取决于脏页刷盘速度，TB级表可能锁几十分钟，业务根本不可接受。必须拆：
- 按主键范围切分，例如
WHERE id BETWEEN 1 AND 10000000，用mysqldump --where导出子集，再用LOAD DATA INFILE导入——这是逻辑补丁，不是物理迁移 - 物理层面只能按表粒度操作，所以真正TB级场景，要提前规划分库分表，让单表控制在100GB以内
- 并发迁移多张表时，注意目标库
innodb_buffer_pool_size是否够用，IMPORT过程会大量读.ibd页，缓冲池不足会导致IO抖动甚至OOM - 迁移后务必运行
ANALYZE TABLE t1;，否则优化器统计信息还是旧的，查询计划可能严重失真
最易被忽略的一点：.cfg文件有效期极短——它只对FLUSH那一刻的表状态有效。哪怕源库只是给表加了个注释，.cfg就作废了。所以从FLUSH到IMPORT之间，任何DDL操作都会让整个迁移链路失败。
