启用binlog压缩传输、调大网络超时、控制单事件大小、避免冗余写入是优化mysql复制传输稳定性的四大关键措施，需按源头减量→事件粒度→传输健壮性→压缩的顺序实施。
启用 Binlog 压缩传输（MySQL 8.0+）
MySQL 8.0.20+ 支持在复制连接中启用压缩协议，能显著减少网络带宽占用，尤其对 ROW 格式下体积膨胀的 binlog 事件效果明显。
- 从库连接主库时需显式指定压缩算法：
CHANGE MASTER TO MASTER_COMPRESSION_ALGORITHMS='zstd'（推荐 zstd，压缩率与解压速度平衡） - 主库无需额外配置，但要求 MySQL 版本 ≥ 8.0.20，且客户端协议支持压缩（
mysql命令行、Connector/J 8.0.22+ 等均支持） - 若主从间存在中间代理（如 ProxySQL），需确认其透传压缩能力，否则可能降级为未压缩传输
- 禁用压缩的典型表现是
SHOW SLAVE STATUS\G中Compression字段显示OFF
调大 NET_READ_TIMEOUT 和 NET_WRITE_TIMEOUT
网络抖动或大事务导致 binlog dump 连接频繁中断，本质是 I/O 线程因超时主动断开重连，引发 relay log 断点重拉和重复传输。
- 主库上执行：
SET GLOBAL NET_READ_TIMEOUT = 120；SET GLOBAL NET_WRITE_TIMEOUT = 120 - 该设置影响所有客户端连接，包括复制 I/O 线程，值单位为秒，建议设为 60～120，避免设过高（如 300）导致故障发现滞后
- 注意：此参数不持久化，需写入
my.cnf的[mysqld]段并重启，或配合PERSIST（MySQL 8.0+）使用 - 若已启用压缩但仍频繁报错
Lost connection to master或error reading from the master，优先检查这两个超时值
控制单个 binlog 事件大小（ROW 格式必调）
ROW 格式下，UPDATE/DELETE 可能携带整行镜像，单条语句生成数 MB 的 binlog event，不仅拖慢主库刷盘，更易触发网络分片与重传。
- 主库设置：
SET GLOBAL binlog_row_event_max_size = 8192（默认 8KB，可调至 16K～32K，单位字节） - 该参数仅对 ROW 格式生效，会将大变更拆分为多个小事件，降低单次网络 payload
- 副作用：略微增加 binlog 文件碎片，但对传输稳定性提升远大于代价
- 搭配
binlog_row_image = MINIMAL使用效果更佳——只记录被修改字段，而非整行
避免 binlog 冗余写入（源头减量）
复制延迟常源于“不该传的日志也传了”，比如监控库、临时表、测试库的变更混入主库 binlog 流。
- 主库配置
binlog_ignore_db = 'monitoring,sysbench_test'（多个库用逗号分隔），比从库replicate_ignore_db更高效——日志根本不出主库 - 严格注意：该参数按当前
USE数据库判断，不是按语句中的库名；DELETE FROM app_log.audit WHERE ...若当前库是app_log且未被忽略，才会写入 - 更安全的替代方案是用
replicate_wild_ignore_table在从库过滤，例如：replicate_wild_ignore_table = 'tmp.%' - 切勿在生产环境同时用
binlog_do_db和binlog_ignore_db，逻辑冲突极易导致复制中断
