启用压缩协议、调整I/O线程参数、优化binlog内容及网络配置可显著提升MySQL主从复制性能，尤其在高延迟或带宽受限环境下，需结合实际业务负载与网络状况综合调优。
MySQL复制的网络性能直接影响主从数据同步的实时性和稳定性，尤其在跨地域、高延迟或带宽受限的环境中更为关键。优化复制网络性能可以从协议效率、数据传输量、连接管理等方面入手，以下是一些实用建议。
启用压缩传输（MySQL 8.0+）
MySQL 8.0引入了replication_compressed_protocol，允许主从之间使用压缩协议传输binlog事件，减少网络流量。
- 在从库连接主库时设置MASTER_COMPRESSION_ALGORITHMS和MASTER_COMPRESSION_LEVEL
- 例如：
CHANGE MASTER TO MASTER_COMPRESSION_ALGORITHMS='zstd', MASTER_COMPRESSION_LEVEL=3; - zstd通常比gzip提供更好的压缩比和更低CPU开销
调整复制I/O线程参数
控制从库读取主库binlog的行为，降低网络频繁交互。
- sync_master_info：适当增大刷新频率，减少磁盘和网络开销
- master_heartbeat_period：调整心跳间隔，避免过频探测增加小包传输
- 在低延迟链路可设为10秒以上，在高延迟环境可适度调低以快速感知中断
优化二进制日志内容
减少不必要的日志输出，从根本上降低传输负载。
- 使用binlog_row_image = MINIMAL，只记录行变更前后必要的字段值
- 避免在主库执行大批量UPDATE/DELETE，拆分为小事务减少单次传输体积
- 排除不需要复制的数据库：binlog_ignore_db 或使用过滤规则
提升网络底层效率
确保TCP/IP层面不成为瓶颈。
- 为主从服务器配置更大的TCP缓冲区（net.core.rmem_max等）
- 启用TCP快速打开（TFO）和BBR拥塞控制（如内核支持）
- 尽量使用内网专线或低延迟链路，避免公网不稳定影响
- 考虑使用SSL但注意加密开销，必要时选用高效加密套件
基本上就这些。关键是根据实际网络状况和业务负载组合使用上述方法，定期监控Seconds_Behind_Master和网络吞吐，找到最优平衡点。不复杂但容易忽略细节。
