slave_compressed_protocol常无效，因需主库≥5.7.17、从库重启io线程且主库cpu不饱和；真正压主库上行带宽须优化binlog内容：设binlog_row_image=minimal、log_slave_updates=off、binlog_transaction_compression=on，并可用tc限速。
主库上行带宽打满，光开 slave_compressed_protocol 没用——它只压从库收包流量，不碰主库发包。
为什么 slave_compressed_protocol 经常没效果
这个参数不是“一设就生效”的开关，而是从库向主库发起连接时的一个协商请求。主库是否响应，取决于三个硬条件：
- 主库 MySQL 版本必须 ≥
5.7.17（旧版本直接忽略该请求） - 从库必须显式执行
STOP SLAVE IO_THREAD; SET GLOBAL slave_compressed_protocol = ON; START SLAVE IO_THREAD;，改完配置不重启 IO 线程等于没设 - 主库 CPU 已满负荷时，压缩反而增加开销，可能被内核自动降级为明文传输
更关键的是：它只压缩 TCP payload 中的 binlog 流，不压缩心跳、ACK、协议头；对单条大事务（比如 UPDATE ... WHERE id IN (1,2,...,10000)）压缩率通常不到 30%，而内网万兆链路下基本无收益。
真正压主库上行带宽，得动 binlog 内容本身
主库网卡 tx 持续跑满，90% 的情况根源不在传输层，而在 binlog 日志体积过大。优先检查并调整：
-
binlog_row_image = MINIMAL：默认FULL会记录整行前后镜像；设为MINIMAL后，只记 WHERE 条件列（前镜像）和实际变更列（后镜像），宽表 UPDATE 场景下日志体积可降 60%+ -
log_slave_updates = OFF：如果从库不作级联中继，关掉它能避免主库多写一份 binlog，直接减半复制相关写入压力 -
binlog_transaction_compression = ON（MySQL 8.0.20+）：在主库侧压缩事务级 binlog 内容，比slave_compressed_protocol更早介入，对大事务效果更稳
注意：binlog_row_image 改完需确认业务逻辑不依赖非主键列判断变更（比如触发器或审计逻辑），否则可能漏同步。
系统层限速比应用层压缩更可控
当带宽瓶颈明确且无法扩容时，tc 是最直接的兜底手段——它不依赖 MySQL 版本，也不增加 CPU 开销：
- 在主库执行：
tc qdisc add dev eth0 root tbf rate 50mbit burst 32kbit latency 400ms（按实际带宽调整rate） - 限速目标应略高于当前平均复制流量（可用
iftop -P 3306实测），避免压死导致 IO 线程频繁重连 - 搭配
slave_net_timeout = 60和master_retry_count = 86400，防止限速引发频繁断连重试
压缩只是锦上添花，真正的带宽控制权，始终在日志内容密度、网络拓扑和主库写入模式手里——一个全表 UPDATE 生成 200MB binlog，再好的压缩也扛不住持续发送。
