MySQL迁移断点续传最稳方案是mydumper+myloader：mydumper按表切分并记录快照位点，myloader通过--resume跳过已成功导入的非空表，但需人工或自动化校验数据一致性。
MySQL 迁移中断后，mysqldump 本身不支持断点续传
直接使用 mysqldump 配合 mysql 进行管道或分步导入，一旦遇到网络抖动导致连接重置，整个过程就会直接宣告失败。原因在于，mysqldump 输出的是一个单一的、流式的 SQL 文件，里面既没有清晰的事务边界标记，也没有记录任何校验位点。连接中断后重来，你根本无法确定“最后成功执行到了哪一条 INSERT 语句”。如果强行继续，结果不是数据重复写入，就是部分数据被跳过，留下一堆烂摊子。
用 mydumper + myloader 实现表级断点续传
那么，有没有更靠谱的方案？答案是肯定的。mydumper 的设计思路就很巧妙：它把整个数据库拆分成多个独立的文件——通常是每张表一个 .sql 文件，外加一个记录全局快照位点的 metadata 文件。而它的好搭档 myloader 则提供了 --resume 参数，能够自动跳过目标库中已经存在的非空表。这套组合拳，目前堪称 MySQL 生态中落地最稳健的断点续传方案。
- 备份阶段：执行
mydumper -h src -u user -p pass -B db1 -o /backup/db1/ --chunk-filesize=64。这里的--chunk-filesize参数是关键，它会按指定大小切分大表，避免单个文件过大，拖慢后续的恢复速度。 - 失败后检查：迁移中途如果失败，先别急着重来。去检查一下
/backup/db1/目录下，哪些.sql文件对应的表在目标库中已经存在，并且行数大致匹配（可以通过查询information_schema.tables来确认）。 - 重试恢复：确认后，使用
myloader -h dst -u user -p pass -B db1 -d /backup/db1/ --resume --threads=4命令重试。加上--resume参数后，它会自动跳过那些已存在的非空表。 - 重要提醒：必须注意的是，
--resume的逻辑仅仅是判断“表是否存在且非空”，它并不校验表内的数据是否完全一致。对于大表，建议同时使用--chunk-filesize和--enable-binlog等参数，以避免对线上主库造成过大压力或导致主从延迟突增。
网络层加固：用 mosh 或 tmux + ssh -o ServerAliveInterval=30
光有应用层的续传能力还不够，我们得从根源上减少中断发生的频率。SSH 默认的超时机制对于动辄数小时的数据库 dump 操作并不友好，很容易因为 TCP 连接空闲而被中间的网络设备掐断。
- 优化 SSH 连接：不要使用默认的
ssh命令，改用ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 user@host。这相当于让客户端定期（每30秒）发送保活包，大大降低被意外断连的风险。 - 使用终端复用器：登录远程主机后，先启动一个
tmux或screen会话，再在里面运行mydumper。这样即使网络断开，进程也会在后台继续运行。重新连接后，只需一个tmux attach命令，就能无缝切回原来的操作界面和日志输出。 - 关于 mosh：虽然
mosh对网络波动的容忍度更高，但它并不适用于典型的 MySQL 迁移场景。因为它不支持 SSH 端口转发，无法通过跳板机连接内网数据库；同时，其 UDP 协议不保证数据包顺序的特性，也不适合传输大容量的、顺序敏感的 SQL 数据流。
真正关键的不是“怎么续”，而是“怎么知道续对了”
这才是问题的核心。断点续传最大的风险，其实在于错误地判断了“成功”状态。举个例子：某张大表在导入到一半时失败，但目标库已经创建了对应的空表结构。此时若使用 myloader --resume，它就会因为“表已存在且非空”（实际上只有结构，没有完整数据）而跳过这张表，导致数据严重丢失。因此，人工核验或自动化的一致性检查，是绝对不能省略的最后一环。
- 行数快速比对：每次运行
myloader前或后，可以写个简单脚本，用类似ls /backup/db1/*.sql | sed 's/\.sql$//' | xargs -I{} mysql -h dst -Nse "SELECT COUNT(*) FROM db1.{}"的命令，快速扫描一遍目标库所有表的行数，然后与源库information_schema.tables中的table_rows进行粗略对比。 - 关键表一致性校验：对于核心业务表，可以在源库导出前，执行
FLUSH TABLES WITH READ LOCK并记录SHOW MASTER STATUS的 binlog 位置，以获得一个一致的快照点。数据恢复完成后，使用pt-table-checksum等专业工具进行行级别的数据一致性比对。 - 理解元数据限制：
mydumper生成的metadata文件里确实有Started dump at:时间戳，但这只是一个逻辑时间点，不等于 GTID 或精确的 binlog 位点。它不能直接用于构建主从关系或确保主从数据完全追平。
说到底，断点续传机制能挽救的是“流程”，但它挽救不了“数据一致性”。网络抖动往往只是表象，背后暴露的，常常是迁移前没有做好流量评估、压力测试以及完备的校验预案。准备工作做到位，才是避免踩坑的根本。
