必须用iperf实测主从链路极限吞吐量，而非依赖业务流量估算；主库执行iperf -s -p 5201，从库执行iperf -c 主库IP -p 5201 -t 60 -i 5，对比瞬时带宽与主库binlog写入速率，若持续偏低则判定网络瓶颈。
用 iperf 实测主从间最大吞吐量
不能只看业务流量估算，必须实测链路极限。MySQL 复制是单 TCP 连接持续推送 binlog，iperf 能模拟这种长连接、高吞吐场景。
在主库执行：iperf -s -p 5201；在从库执行：iperf -c 主库IP -p 5201 -t 60 -i 5。观察每 5 秒输出的瞬时带宽，重点关注是否持续低于主库峰值写入速率（比如主库 binlog 写入稳定在 80MB/s，而 iperf 最大仅跑出 45MB/s，就说明网络已成瓶颈）。
- 测试前关闭防火墙或放行
5201端口，避免干扰 - 务必在业务低峰期执行，否则结果会被其他流量污染
- 若跨机房部署，需分别在两个机房内网各选一台机器互测，排除骨干网抖动干扰
对比 binlog 生成速率与 relay log 写入速率
网络瓶颈的典型表现是：主库 binlog 增长快，但从库 Relay_Log_Space 增长慢，且 Slave_IO_Running: Yes 但 Seconds_Behind_Master 持续上涨。
查主库当前 binlog 写入速度：mysql -e "show master status\G" | grep Position，配合定时采集计算每秒增量；再查从库：SHOW SLAVE STATUS\G 中的 Relay_Log_Space 字段，同样定时采集。若后者增速长期只有前者的 60% 以下，基本可判定 IO Thread 受限于网络接收能力。
- 注意：
Relay_Log_Space包含未刷盘日志，需结合iostat -x 1观察从库磁盘 %util 是否偏低（ - 如果主库
Binlog_cache_use很高，说明小事务多，更依赖网络低延迟而非绝对带宽，此时应关注 ping 延迟和TCP_NODELAY设置
检查 MySQL 复制连接的实际吞吐与重传
MySQL 的 dump 线程本质是 TCP 客户端/服务端模型，直接看连接状态比看业务指标更准。
在从库上执行：ss -ti | grep :3306（假设主库端口是 3306），找对应主库 IP 的连接行，观察其中的 retrans（重传次数）、rcv_rtt（接收往返时延）、rcv_space（接收窗口大小）。若 retrans 持续增长，或 rcv_rtt 明显高于同机房其他服务（如 >5ms），说明网络不稳定或丢包；若 rcv_space 长期卡在 64KB 附近，说明 TCP 接收窗口未自动调优，限制了吞吐。
- Linux 4.9+ 可启用 BBR：
sysctl -w net.ipv4.tcp_congestion_control=bbr，对高延迟链路提升明显 - MySQL 连接默认不设
TCP_NODELAY，小包会攒批发送，加剧延迟；需在主库my.cnf加set-variable=slave_compressed_protocol=1并确认从库也启用压缩
别被 Seconds_Behind_Master 的“0”骗了
Seconds_Behind_Master 显示为 0，不代表网络没问题。它只反映“最后一条已回放事务的提交时间差”，当 IO Thread 还没拉到新日志时，这个值就停摆。
真正要看的是：SHOW SLAVE STATUS\G 中的 Master_Host + Master_Port 对应的连接是否活跃，以及 Relay_Master_Log_File 和 Exec_Master_Log_Pos 是否在缓慢推进。如果这两项几乎不动，而 Slave_IO_Running: Yes，大概率是网络卡在建立连接或持续传输阶段。
- 用
tcpdump -i any port 3306 and host 主库IP -w replicate.pcap抓包，过滤出 dump 协议流，看是否有大量重传或 ACK 延迟 - 宝塔面板用户特别注意：
/www/server/mysql/etc/my.cnf的修改可能被/etc/my.cnf或/www/server/mysql/etc/my.cnf.d/*.cnf覆盖，必须用mysql --help | grep "Default options"确认实际加载路径
STOP SLAVE SQL_THREAD），只留 IO Thread 运行，单独压测 relay log 写入速率，才能把网络问题真正拎出来。 
