迁移时需调大wait_timeout和interactive_timeout至约24.8天以防断连，同步增大max_allowed_packet至512M避免大包截断，并优化TCP参数如tcp_tw_reuse、缓冲区及禁用Nagle算法；内网迁移应关闭SSL以保性能。
迁移时连接超时：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 内核才是数据真正穿行的管道。
