slave_compressed_protocol 参数用于控制MySQL主从复制是否使用压缩协议，基于ROW格式的binlog，其数据量一直是一个比较大的问题，开启binlog复制压缩对于缓解binlog数据量大导致的网络带宽问题有一定的帮助，那么开启slave_compressed_protocol参数后，网络传输的binlog压缩效果如何？对其他性能是否会产生影响？本文通过实验进行验证。
1、测试环境：
- 16核32G虚拟机
- MySQL版本：5.7.19
- 1主1从，异步复制
2、测试结果：
| 主库cpu | 从库cpu | 主库send | 主库recv | 从库send | 从库recv | |
|---|---|---|---|---|---|---|
| 未压缩 | 22% | 20% | 6.18MB/s | 3.49MB/s | 108KB/s | 5.38MB/s |
| 压缩 | 22% | 20% | 3.64MB/s | 3.52MB/s | 88.5KB/s | 2.65MB/s |
注：
开启或者关闭slave_compressed_protocol参数，需要重启复制，让该参数生效。
3、结论
- 开启slave_compressed_protocol参数，压缩效果明显，网络数据传输量约为未开启一半，压缩率50%。
- 开启slave_compressed_protocol参数，主从库cpu负载没有明显的增长。
注：
MySQL 5.7 和 8.0 的某些版本在slave_compressed_protocol=ON与半同步复制一起使用时，会触发Bug。具体见链接：
MySQL 5.7 Bug slave_compressed_protocol 与半同步复制同时开启，导致主库写入卡住
