跨地区MySQL迁移应优先保障数据流稳定，推荐mysqldump | gzip | ssh管道直传，避免磁盘I/O；需同步调大max_allowed_packet、net_buffer_length及TCP参数，并根据场景选用分片rsync或mydumper并发方案。
跨地区 MySQL 迁移卡在带宽上，核心问题不是“怎么压得更小”，而是“怎么让数据流不中断、不绕路、不被系统掐脖子”。直接走 mysqldump | gzip | ssh 管道是最简有效路径，但必须同步调参、绕开默认陷阱。
为什么 mysqldump 直传管道比先写文件再 scp 快一倍？
本地落盘再传，等于把同一份数据读一次磁盘 + 写一次磁盘 + 上传一次网络；而管道是内存直出 → 压缩 → 加密 → 解密 → 导入，全程无磁盘 I/O。实测百 GB 级迁移，省下 30–50% 总耗时。
-
mysqldump输出直接进gzip，别加pv在中间（会成瓶颈），真要测速就放最后：| gunzip | pv -b | mysql - MyISAM 表必须用
--lock-all-tables，InnoDB 才能靠--single-transaction避免锁表 - 如果目标库还在提供读服务，
--skip-extended-insert别开——它会让每行一个 INSERT，SQL 解析开销翻倍，反而拖慢导入
哪些参数不调大，管道必断？
max_allowed_packet 和 net_buffer_length 是管道传输的“水管口径”。默认 4MB 在导 BLOB 或长文本时，源端还没发完，目标端就报 MySQL server has gone away。
- 两边都改：源库和目标库的
my.cnf中设max_allowed_packet = 512M、net_buffer_length = 1M - 客户端也要显式指定：
mysql --max-allowed-packet=512M -h localhost db_name - 目标库还得检查
innodb_log_file_size，太小会导致大批量 INSERT 触发频繁 checkpoint，IO 拉满，表面是网络慢，实际是磁盘堵死
ssh 管道老断连？不是网络差，是 TCP 参数太保守
跨地区链路 RTT 高、丢包率略高时，ssh 默认的 TCP 行为会频繁重传、慢启动，导致吞吐骤降。这不是 MySQL 的锅，是内核没配好。
- ssh 加选项防断：
ssh -o "TCPKeepAlive=yes" -o "ServerAliveInterval=30" user@host - Linux 服务器关掉空闲连接重置慢启动：
sysctl -w net.ipv4.tcp_slow_start_after_idle=0，并写入/etc/sysctl.conf - 调大 TCP 缓冲区（尤其万兆内网）：
net.ipv4.tcp_rmem = 4096 262144 16777216，配套net.core.rmem_max也得同步拉高，否则无效
大库（>100GB）别硬扛管道，分片 + rsync 才稳
单管道扛不住长时间传输：ssh 超时、MySQL 连接闪断、目标端磁盘满，都会导致从头再来。分表导出 + rsync --partial 是生产环境兜底方案。
- 按表导出：
mysqldump -u root -p db_name table1 table2 | gzip > db_table12.sql.gz - 传的时候加
--partial：rsync -avz --partial --progress db_table12.sql.gz user@host:/backup/ - 目标端校验再导入：
md5sum db_table12.sql.gz对齐后，再gunzip | mysql - 真正要提速，换
mydumper -t 4并发导出，生成schema.sql+ 每张表独立.sql.gz，天然支持并行 rsync 和myloader -t 4导入
最容易被忽略的是：压缩本身在内网几乎没收益，还吃 CPU；而 skip-name-resolve 不关，DNS 反查可能让每次连接多等几百毫秒——这些细节不处理，再大的带宽也喂不饱管道。
