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：按大小切分大表，避免单文件过大拖慢恢复 - 迁移中途失败后，检查
/backup/db1/下哪些.sql文件对应的目标表已存在且行数匹配（可查information_schema.tables） - 重试时加
myloader -h dst -u user -p pass -B db1 -d /backup/db1/ --resume --threads=4，它会自动跳过目标库中已存在的非空表 - 注意：
--resume只判断表是否存在且非空，不校验数据一致性；大表建议配合--chunk-filesize和--enable-binlog避免主从延迟突增
网络层加固：用 mosh 或 tmux + ssh -o ServerAliveInterval=30
单纯靠应用层续传不够，得先减少中断频次。SSH 默认超时机制对长时 dump 不友好，容易因 TCP idle 被中间设备断连。
- 不用裸
ssh，改用ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 user@host，主动保活 - 进远程终端后先启
tmux，再跑mydumper；断线重连后tmux attach即可继续看日志，进程其实没丢 -
mosh不适用 MySQL 迁移场景——它不支持端口转发，无法穿透跳板机连内网 DB，且不保证 TCP 顺序，不适合传输大 SQL 流
真正关键的不是“怎么续”，而是“怎么知道续对了”
断点续传最大的坑是误判成功状态：比如某张表导入一半失败，但目标库已建好空表，myloader --resume 就会跳过它，导致数据丢失。必须人工核验或加自动化检查。
- 每次运行
myloader前，用ls /backup/db1/*.sql | sed 's/\.sql$//' | xargs -I{} mysql -h dst -Nse "SELECT COUNT(*) FROM db1.{}"扫一遍目标表行数，和源库SELECT table_rows FROM information_schema.tables对比 - 对关键表，导出前在源库打
FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS，记录 binlog 位置；恢复后用pt-table-checksum做行级比对 -
mydumper的metadata文件里有Started dump at:时间戳，但它不等于 GTID 或 binlog 位点，不能直接用于主从追平
断点续传能救流程，但救不了数据一致性。网络抖动只是表象，背后往往是没做限流、没压测、没校验的迁移准备。
