mysql如何优化主从同步中的网络带宽占用_开启slave_compressed

slave_compressed_protocol仅压缩从库接收binlog的传输流量，压缩率30%–50%，对主库上行带宽无效；需主库≥5.7.17、从库显式启用并重启IO线程，内网高带宽下收益低且增CPU开销；更优方案是调小binlog_row_image、关闭log_slave_updates或用tc限速。

mysql如何优化主从同步中的网络带宽占用_开启slave_compressed_protocol

开启 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;

验证是否真正启用：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

从库执行 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