迁移耗时根本不由“数据量”单独决定
直接说结论：100GB 数据可能 2 小时迁完，也可能拖 3 天——关键不在大小，而在你选的路径是否匹配当前环境。比如用
mysqldump导出再导入 5000 万行 InnoDB 表，没调参的话很可能卡在单线程写入和频繁事务提交上；而用
xtrabackup物理拷贝，同一份数据在千兆内网下通常 20–40 分钟就能完成全量复制。
四种主流方式的真实耗时对比（基于 TB 级实测经验）
以下时间范围来自 2025 年底多个生产环境（源/目标均为 16C32G + NVMe SSD，千兆内网）：
mysqldump+
mysql导入：100GB 数据约 6–12 小时（默认参数下），加
--single-transaction --skip-triggers --disable-keys -e可压到 3–5 小时，但依然受网络延迟和目标端 IO 写入瓶颈制约
mydumper/
myloader（16 线程）：100GB 数据约 1.5–2.5 小时；注意
myloader需提前在目标库执行
SET unique_checks=0; SET foreign_key_checks=0;，否则索引重建会拖慢 3 倍以上
LOAD DATA INFILE（配合
SELECT ... INTO OUTFILE）：100GB CSV 文件导入约 40–70 分钟；但要求源/目标在同一台机器或挂载共享存储，且
secure_file_priv必须放开对应路径
xtrabackup全量热备+恢复：100GB 数据备份约 12–18 分钟，传输（rsync）约 25 分钟，
--prepare+
--copy-back约 8–15 分钟，总计约 50 分钟内可完成——这是目前最快、最稳的整库迁移路径
真正拖慢迁移的三个隐藏因素
很多人盯着“导出速度”看，却忽略了更致命的三件事：
目标库写入阻塞：未关闭innodb_flush_log_at_trx_commit=1或
sync_binlog=1时，每条 INSERT 都刷盘，IO 直接打满；建议迁移期临时设为
2和
0，完成后立即改回 索引重建开销被低估：
myloader或
mysql导入时若未禁用唯一性检查，它会在每批数据后重建二级索引——1 亿行表加 3 个索引，重建时间可能超过数据导入本身 网络传输不是瓶颈，而是“伪瓶颈”：用
mysqldump | ssh mysql看似省事，但 TCP 缓冲区默认太小（
net_buffer_length=16K），大字段会导致大量小包重传；必须显式加
--net-buffer-length=1048576和
--max-allowed-packet=512M
怎么预估自己这次要多久？动手前必做三件事
别猜，直接测。哪怕只抽 1% 数据跑一次最小闭环：
用SELECT COUNT(*) FROM table_name;和
SELECT data_length + index_length FROM information_schema.tables确认真实体积（有些表
data_length是 0，因为用了压缩或分区） 在业务低峰期，对一张典型大表（比如 500 万行）跑一次
mydumper -t 4 -B db -T table+
myloader -t 4 -d /tmp/dump，记下耗时，再按比例外推（但乘 1.8 系数，因为并发越高，锁争抢越明显） 用
pt-table-checksum在源/目标间抽样比对 10 个分片，看 checksum 是否一致——很多“迁完了却丢数据”的问题，其实发生在最后 1% 的 binlog 追平阶段，而非主迁移过程
真正麻烦的从来不是“怎么快”，而是“怎么不丢、不错、不卡住应用”。物理备份快，但要求停机窗口或严格校验；逻辑迁移可控，但参数一漏就慢十倍。动手前多花 20 分钟测一组真实数据，比事后重跑三天强得多。
