迁移时连接超时：wait_timeout
和 interactive_timeout
必须调大
MySQL 默认的
wait_timeout是 28800 秒（8 小时），但实际迁移工具（如
mysqldump、
mydumper或应用直连同步）在长事务、大表导出或网络抖动时，很容易因空闲等待超时被服务端主动断连，报错类似
Lost connection to MySQL server during query。 建议在迁移前，在目标/源库的
my.cnf中临时设为
wait_timeout = 2147483（约 24.8 天，MySQL int 最大值），
interactive_timeout同步调整 仅需改服务端配置，客户端无需对应修改；但要注意该设置对所有连接生效，迁移完建议恢复合理值（如 7200） 如果用
mysqldump，加上
--skip-extended-insert可减少单条语句长度，降低因语句执行慢触发超时的概率
大包传输失败：max_allowed_packet
不够会静默截断
迁移中遇到 INSERT 语句突然中断、数据少几行、或者
Packet for query is too large报错，基本就是
max_allowed_packet溢出。它控制服务端能接收/返回的最大单个 packet，而 mysqldump 默认每行生成一个 INSERT，但带
--extended-insert（默认开启）时会拼成超长语句，极易突破默认 4MB 限制。 源库和目标库都需调高：在
my.cnf中设
max_allowed_packet = 512M（注意单位是 M，不是 MB） 若用
mysql客户端导入 SQL 文件，也要加参数：
mysql --max_allowed_packet=512M -u user -p db调太大可能增加内存压力，512M 对百 GB 级迁移已足够；不建议设为 0（表示无限），MySQL 8.0+ 已弃用该用法
网络重传与缓冲：TCP 层优化比 MySQL 参数更关键
跨机房、云厂商 VPC 间迁移时，真正卡顿往往不在 MySQL 内部，而在 TCP 层丢包重传。MySQL 自身无重传机制，一次丢包就导致整个 packet 重发，叠加延迟后表现就是「卡住几秒后突然继续」。
在迁移机器上启用tcp_tw_reuse = 1（允许 TIME_WAIT socket 重用），避免高并发连接耗尽端口 调大 TCP 接收/发送缓冲区：
net.core.rmem_max和
net.core.wmem_max至 16M～32M，配合
net.ipv4.tcp_rmem/
tcp_wmem的三元组动态扩缩 禁用 Nagle 算法（
tcp_nodelay = 1）对小包密集场景（如 binlog 同步）有效，但对 mysqldump 这类大块写入收益不大，可不改
SSL 加密迁移：性能损耗真实存在，非必要不启用
如果迁移链路本身已在内网或 VPC 内（如阿里云经典网络、AWS VPC peering），强制开启
require_secure_transport = ON或客户端加
--ssl-mode=REQUIRED，会引入明显 CPU 开销和 RT 延迟，尤其在万兆以下网卡上，吞吐可能下降 20%～40%。 确认链路是否真需加密：公网迁移必须开 SSL；内网迁移优先走白名单 + 安全组控制，关 SSL 更稳更快 若必须开 SSL，用 TLS 1.3（MySQL 8.0.28+ 支持），比 TLS 1.2 握手快、加密快；避免用自签名证书，验证开销高
ssl_cipher配置不要留空，默认值已足够；过度限定（如只允
ECDHE-ECDSA-AES256-GCM-SHA384）反而可能因协商失败中断连接
网络延迟不是孤立问题，它把配置偏差、协议选择、硬件边界全暴露出来。最容易被跳过的其实是 TCP 参数调优——很多人只盯着
my.cnf，却忘了 Linux 内核才是数据真正穿行的管道。
