MySQL 8.0.20+主库启用binlog_transaction_compression后，事务级ZSTD压缩在提交时完成，压缩后数据直接写入本地binlog并发送至从库，从库仅被动接收不解压，无需配置参与决策。
binlog_transaction_compression 必须在主库启用，从库不参与压缩决策
MySQL 8.0 的 binlog 压缩是「主库端事务级压缩」，不是传输协商机制。开启 binlog_transaction_compression = ON 后，主库会用 ZSTD 算法对每个事务的 binlog event 进行压缩，压缩后的数据写入本地 binlog 文件，也直接发给从库——从库收到的就是已压缩内容，无需额外配置或解压逻辑。
常见误解是把它和 slave_compressed_protocol 混为一谈，后者只压缩 TCP payload、需主从配合、且仅限于 IO 线程拉取阶段；而 binlog_transaction_compression 是源头压缩，影响存储 + 网络双重体积，主库一开，所有下游（包括备份、归档、级联从库）自动受益。
- 必须 MySQL 8.0.20+ 才支持该功能（早期 8.0.x 版本不包含）
- 不能只在从库设，从库设了
binlog_transaction_compression完全无效 - 压缩发生在事务提交时，所以高并发小事务场景下 CPU 开销比大事务更明显
- 若主库已启用了
binlog_row_image = MINIMAL，再开压缩，带宽节省是叠加效果，不是重复优化
压缩级别调多少才合理：别盲目设成 22
binlog_transaction_compression_level_zstd 默认是 3，范围 1–22。数值越高，压缩率略升但 CPU 占用非线性增长——实测从 3 升到 12，压缩率提升不到 8%，但主库 CPU sys 时间可能多出 15%~25%。
真实业务中，绝大多数场景用默认值 3 或设为 6 就足够。除非你确认主库 CPU 有富余、且网络是千兆以下（如跨城专线）、且 binlog 日均体积超 50 GB，才考虑提到 12 以上。
- 设为 1：压缩率低，几乎不耗 CPU，适合写入极密集、CPU 已近瓶颈的 OLTP 主库
- 设为 3（默认）：平衡点，ZSTD 在该级别下解压速度最快，从库 relay log 写入延迟几乎无感知
- 设为 22：仅建议离线归档场景用，线上主库慎用；超过 15 后压缩收益急剧衰减
- 修改后无需重启 mysqld，但必须动态生效：
SET GLOBAL binlog_transaction_compression_level_zstd = 6;
为什么开了压缩，ifconfig 看主库网卡 tx 流量没降？
开了 binlog_transaction_compression 却没看到网络带宽下降，大概率是因为：主库产生的 binlog 本身就不大，或者复制流量根本不是瓶颈。
先验证是否真由复制导致带宽打满：用 iftop -P 3306 或 ss -i src :3306 看主库 3306 端口的实时发送速率；再对比 SHOW BINARY LOGS; 中最近 1 小时日志总大小，换算成平均 KB/s —— 如果两者差 3 倍以上，说明带宽占用主力不是 binlog 复制（可能是其他客户端长连接、备份工具、监控采集等）。
- 一个 UPDATE 涉及 10 万行但只改一个字段，在
binlog_row_image = MINIMAL下生成日志可能不到 1 MB，压缩后省不了多少字节 - 如果主从同机房千兆内网，TCP 层吞吐远高于 binlog 实际产出，压缩带来的带宽节省被链路余量吃掉，监控上根本看不出来
- 抓包验证最可靠：在主库执行
tcpdump -i any port 3306 -w comp.pcap，开启压缩前后各抓 60 秒，用 Wireshark 看 TCP payload 平均大小变化
比压缩更关键的三件事，优先检查
压缩只是“锦上添花”，真正卡住主从带宽的，往往是 binlog 内容密度和写入模式本身。在折腾压缩参数前，务必确认这三点：
- 确认
binlog_row_image是MINIMAL而非FULL：后者会让每条 UPDATE 记录整行旧值+新值，体积翻几倍；MINIMAL只记变更列和主键，压缩前就已大幅瘦身 - 确认
log_slave_updates在从库上是OFF（除非你要做级联复制）：主库不需要为从库的 relay log 再写一份 binlog，否则等于复制流量 ×2 - 检查是否有巨型单事务：比如一个全表 UPDATE 或大批次 INSERT，它生成的单个 binlog event 可能上百 MB，ZSTD 对超大 payload 压缩效率会下降，且从库 SQL 线程回放时容易卡住
压缩解决不了低效日志内容问题。一个没主键的表被频繁 UPDATE，即使开了压缩，binlog 体积仍会因哈希匹配逻辑膨胀，这时候该加主键，而不是调压缩级别。
