开启binlog_transaction_compression后，仅备份binlog文件时体积下降（实测压缩率2.5–4x），而mysqldump、mydumper等逻辑备份及xtrabackup物理备份（未加--backup-binlog）完全不受影响。
直接结论：开启 binlog_transaction_compression 后，备份体积是否下降，取决于你备份的是什么——如果是 mysqldump 或逻辑导出，它完全不受影响；只有备份 binlog 文件本身（如 cp、rsync 或 xtrabackup --backup-binlog）时，压缩才生效。
备份 binlog 文件时，压缩才起作用
MySQL 的 binlog 压缩是「事务级源头压缩」，不是传输或归档层的二次压缩。一旦 binlog_transaction_compression = ON，每个事务提交时就会用 ZSTD 把 event 内容压进 binlog 文件，磁盘上存的就是已压缩数据。
- 你用
cp /var/lib/mysql/mysql-bin.000001 ./backup/备份，文件体积明显变小（实测通常压缩率 2.5–4x） - 你用
xtrabackup --backup-binlog备份，同样拿到压缩后的原始 binlog 文件 - 但
mysqldump、mydumper或任何基于 SQL 导出的工具，读的是当前数据快照，根本不碰 binlog，所以压缩对它们零影响 - 同理，物理备份（如
xtrabackup --backup）只备份 InnoDB 数据文件和未压缩的 redo log，也不包含 binlog，除非显式加--backup-binlog
必须 MySQL 8.0.20+，且仅主库配置有效
该功能从 8.0.20 才引入，早于这个版本（包括所有 8.0.19 及之前）即使配置了也会被忽略，SHOW VARIABLES LIKE 'binlog_transaction%' 返回空或默认值。
- 只在主库设
SET GLOBAL binlog_transaction_compression = ON即可，从库设了无效，也不需要同步配置 - 确认生效：执行
SHOW BINARY LOGS;查看最新 binlog 文件大小，再对比开启前同时间段生成的文件（注意避开 rotate 频繁期） - 验证压缩是否真实写入：用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | head -20，如果看到Transaction_payload_log_event且compression_type: ZSTD，说明压缩已生效
压缩级别别乱调，默认 3 最稳妥
binlog_transaction_compression_level_zstd 默认是 3，范围 1–22。这不是“越高越好”的参数，而是 CPU 和体积的权衡点。
- 设为 1：几乎不压缩，CPU 几乎无开销，适合写入密集、CPU 已打满的 OLTP 主库
- 设为 3（默认）：ZSTD 解压最快，从库 relay log 写入延迟无感知，压缩率约 3x，推荐绝大多数场景
- 设为 6：压缩率略升（+5% 左右），CPU sys 时间多 10%~15%，适合网络带宽紧张但 CPU 有余量的环境
- 设为 12 以上：压缩率收益急剧衰减（+2%~3%），CPU 开销却翻倍，线上主库慎用；仅建议离线归档时临时启用
- 修改后无需重启：
SET GLOBAL binlog_transaction_compression_level_zstd = 6;立即生效
别指望它解决所有备份压力
binlog 压缩只影响 binlog 文件体积，对其他备份路径完全透明。如果你的备份瓶颈不在 binlog 上，比如：
- 每天全量
mysqldump生成 200 GB SQL 文件 → 压缩 binlog 毫无帮助，应考虑分库分表导出或改用物理备份 - 用
xtrabackup备份 1 TB InnoDB 表空间 → binlog 压缩不减少 backup 目录大小，应关注innodb_file_per_table和innodb_page_size - binlog 日均增长才 200 MB，而网卡流量打满是因为慢查询刷屏或监控拉取频繁 → 先查
iftop -P 3306，别盲目调 binlog 参数
真正依赖 binlog 的场景（如 PITR 精确恢复、跨机房日志归档、CDC 接入）才值得投入精力调优这个开关。其余时候，保持默认即可。
