slave_compressed_protocol仅压缩从库接收binlog的传输流量，压缩率30%–50%，对主库上行带宽无效；需主库≥5.7.17、从库显式启用并重启IO线程，内网高带宽下收益低且增CPU开销；更优方案是调小binlog_row_image、关闭log_slave_updates或用tc限速。
开启 slave_compressed_protocol 确实能压网络带宽，但只对从库接收 binlog 的流量有效，且压缩率有限（通常 30%–50%），别指望它解决主库上行打满的问题。
为什么 slave_compressed_protocol 有时没效果
这个参数控制的是从库在连接主库时，是否要求主库用 zlib 压缩中继日志流。但它生效有硬性前提：
- 主库 MySQL 版本必须 ≥ 5.7.17（旧版本忽略该请求）
- 从库发起连接时必须显式启用，主库不会主动压缩；如果主库已满负荷发包，压缩反而增加 CPU 开销
- 若主从之间走的是内网千兆/万兆链路（比如云厂商同 VPC），压缩收益几乎为零，还白耗 CPU
- 它不压缩 binlog 文件本身，只压缩传输过程中的 TCP payload，所以对大事务的单条语句（如
UPDATE ... WHERE id IN (1,2,...,10000)）压缩效果差
slave_compressed_protocol = ON 的正确启用方式
必须在从库上设置并重启 IO 线程，不是改完就自动生效：
STOP SLAVE IO_THREAD; SET GLOBAL slave_compressed_protocol = ON; START SLAVE IO_THREAD;
验证是否真正启用：
- 从库执行
SHOW PROCESSLIST，找system user连接主库的线程，State 显示Master has sent all binlog to slave; waiting for more updates且 Command 为Binlog Dump—— 这说明 IO 线程已重建，压缩可能已启用 - 更可靠的方式是抓包：在主库执行
tcpdump -i any port 3306 -w dump.pcap，对比开启前后平均 TCP 包 payload 大小（需过滤掉心跳和 ACK）
比压缩更有效的带宽控制手段
当主库网卡 tx 持续跑满，优先排查和处理这些：
- 确认是否真由复制引起：用
iftop -P 3306或ss -i看主库 3306 端口发送速率，而不是只盯Seconds_Behind_Master - 降低日志体积：把
binlog_row_image设为MINIMAL（需确保业务无UPDATE依赖非主键列判断变更的逻辑） - 禁用不必要的日志生成：如果从库不作级联中继，设
log_slave_updates = OFF，避免主库多写一份 binlog - 系统层限速更直接：用
tc在主库限制 mysqld 出向流量，例如tc qdisc add dev eth0 root tbf rate 8mbit burst 32kbit latency 400ms
压缩只是辅助手段，真正的瓶颈往往藏在 binlog 内容密度、网络拓扑或主库写入模式里——比如一个全表 UPDATE 生成几百 MB binlog，压缩再好也扛不住持续发送。
