别用 mysqldump 远程直连导出，本地压缩 + rsync over ssh 是异构网络下最稳的组合；因其规避tcp长连接风险，支持断点续传、ssh保活、并行压缩及端到端sha256校验，确保大库跨防火墙/nat/安全组迁移可靠。
直接结论：别用 mysqldump 远程直连导出，本地压缩 + rsync over SSH 是异构网络下最稳的组合。 异构网络（比如源端是内网IDC、目标端是公有云VPC、中间穿防火墙/NAT/安全组）意味着TCP连接不可靠、带宽波动大、MTU不一致、甚至SSH跳板限制。此时任何依赖长连接或MySQL协议直传的方案（如 mysqldump -h remote 或 mysqlpump --defaults-file）都容易卡死、超时、丢包或被重置。
为什么 mysqldump 远程导出在异构网络下大概率失败
远程执行 mysqldump -h 10.20.30.40 -u root -p db_name 本质是建立一条从本地到远端MySQL的TCP长连接，并持续接收SQL流。异构网络中常见问题包括：
- 中间防火墙对空闲连接主动断连（
TIME_WAIT堆积或会话老化） - NAT设备因UDP/TCP会话表满导致新包丢弃，表现为“Connection reset by peer”
- MTU不匹配引发分片失败，
tcpdump可见大量重传和dup ACK - MySQL服务器未配置
wait_timeout和interactive_timeout（默认8小时），但实际网络层早于该值就中断了
rsync over SSH 是异构网络传输备份文件的首选
rsync 不依赖MySQL服务状态，只依赖SSH可达性——而SSH通常比3306更易通过防火墙策略放行，且支持重试、断点续传、压缩、限速和完整性校验。
- 必须加
--partial：传输中断后可续传，避免重头开始（对GB级备份至关重要） - 推荐加
--bwlimit=5120（单位KB/s）：防止占满带宽影响线上业务 - 用
-e "ssh -o ConnectTimeout=10 -o ServerAliveInterval=30"显式控制SSH保活，避免假死 - 传输前确保目标端
~/.my.cnf已配好密码（避免导入时交互输入），且权限为600
压缩策略要匹配网络与CPU资源博弈
异构网络往往带宽受限但源/目标服务器CPU较富余，优先选并行压缩工具，而非单纯gzip：
- 用
pigz替代gzip：多核并行压缩，耗时可降60%以上，命令为mysqldump ... | pigz > backup.sql.gz - 若目标端IO慢（如云盘IOPS低），改用
zstd -T0（自动用满CPU）+ 更高压缩比，解压速度也快于gzip - 禁止在弱网环境下“边传边解压”：像
mysqldump | gzip | ssh "gunzip | mysql"这类管道链，在异构网络中极易因一环阻塞导致全链失败
传输后必须校验，不能只看文件大小
异构网络中CRC校验错、静默丢包、磁盘写入失败都可能让文件“看起来完整”但实际损坏。必须做端到端一致性验证：
- 源端生成SHA256：执行完压缩后立刻运行
sha256sum backup.sql.gz > backup.sql.gz.sha256 - 传输
.sha256文件本身（它极小，几乎不增加开销） - 目标端校验：
sha256sum -c backup.sql.gz.sha256，输出OK才算可信 - 额外建议：导入前先用
gunzip -t backup.sql.gz测试解压可用性，再用head -n 100 backup.sql.gz | gunzip | head确认SQL头有效
真正容易被忽略的是：异构网络下，rsync 的 --checksum 参数几乎没用——它校验的是修改时间+大小，默认不触发全量比对；而 --ignore-times 又太暴力。所以务必坚持“本地生成校验码 → 传双文件 → 远端校验”，这是唯一能覆盖网络层不可靠性的闭环。
