根本原因是默认超时参数不适应高延迟网络，需协同调大slave_net_timeout（120～300秒）、net_read_timeout和net_write_timeout（均≥180秒），并启用slave_compressed_protocol=1、禁用Nagle算法及GTID多线程复制。
为什么跨机房主从复制老断连
根本原因是默认超时参数完全不适应高延迟网络。比如 RTT 达到 200ms 时，slave_net_timeout=60（默认值）意味着只要 IO 线程连续 60 秒没收到任何数据包就直接断开——而一次轻微抖动或主库短暂卡顿就可能触发它。紧接着报错 ERROR 2013 (HY000): Lost connection to MySQL server during query，重连后又因位点丢失或 relay log 损坏反复失败。
必须调大的三个超时参数
它们不是孤立的，必须协同调整：
-
slave_net_timeout：设为120～300（单位秒），必须 ≥ RTT × 3；实测中若 RTT 波动在 150–250ms，建议直接设240 -
net_read_timeout和net_write_timeout：均需 ≥180，否则 IO 线程在读写 binlog 流时仍会提前中断 - 所有参数都要在从库的
my.cnf中配置，并重启 mysqld 生效；仅用SET GLOBAL临时修改无效（IO 线程启动时只读取配置文件）
启用压缩和禁用 Nagle 算法
跨机房带宽常是瓶颈，小包延迟又加剧同步毛刺：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 在从库配置中开启
slave_compressed_protocol=1，可减少 30%～50% 的 binlog 传输体积，但注意主库 MySQL 版本需 ≥ 5.7.9 才支持解压 - Linux 层禁用 Nagle 算法：
sysctl -w net.ipv4.tcp_nodelay=1，避免 TCP 将多个小包合并发送导致日志拉取延迟突增 - 不要依赖应用层连接池设置
TCP_NODELAY，MySQL 复制线程走的是底层 socket，必须系统级生效
binlog 格式与传输协议的隐性影响
很多人忽略 binlog 格式对网络压力的放大效应：
- 用
STATEMENT格式时，一条 UPDATE 可能被重放多次（如含 NOW()、RAND()），且从库解析开销大；ROW格式虽体积略大，但语义确定、无歧义，网络传输更“可预测” -
binlog_row_image=FULL是安全前提，但若业务大量更新宽表且只改个别字段，可评估是否用MINIMAL（需确认所有从库版本 ≥ 5.6.22） - 绝对不要用
mysqlbinlog --read-from-remote-server拉日志——它不重试、不校验、不续传，跨机房丢一个包就全链路崩
最易被忽略的一点：这些网络层优化必须和 GTID + 并行复制配合使用。光调大超时只能“不断连”，但延迟仍会累积；没有 slave_parallel_type=LOGICAL_CLOCK，单个慢事务就能卡死整个 SQL 线程，让所有后续日志排队等待。
