MySQL 8.0+主从复制启用zstd压缩需在CHANGE MASTER TO中显式指定COMPRESSION_ALGORITHM='zstd'和COMPRESSION_LEVEL=3，并强制启用MASTER_SSL=1；仅服务端配置无效，且须配合心跳、半同步及max_allowed_packet调优才能真正提升公网复制稳定性。
MySQL 8.0+ 主从复制启用 zstd 压缩协议
跨公网部署主从时，不加压缩的 binlog 传输极易打满带宽，尤其当主库写入频繁、含大量 JSON 或文本字段时。MySQL 8.0.21 起原生支持 COMPRESSION_ALGORITHM 和 COMPRESSION_LEVEL，比旧版 slave_compressed_protocol = ON 更可控、更高效。
在从库执行 CHANGE MASTER TO 时必须显式指定压缩参数，仅靠服务端配置无效：
CHANGE MASTER TO MASTER_HOST='master-public-ip', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_SSL=1, COMPRESSION_ALGORITHM='zstd', COMPRESSION_LEVEL=3;
-
zstd是目前最优选：相比zlib，同等压缩率下 CPU 开销低 30–40%，ARM 架构（如 AWS Graviton）上优势更明显 -
COMPRESSION_LEVEL=3是平衡点；设为 1 太弱（压缩率 ~1.2x），设为 9 则 CPU 升高但收益不明显（压缩率仅再提升 5–8%） - 必须搭配
MASTER_SSL=1—— 公网环境不启 SSL，压缩参数会被忽略（MySQL 内部校验逻辑） - 执行后需
START SLAVE，且SHOW SLAVE STATUS\G中的Compression_algorithm字段要显示zstd才算生效
为什么开了压缩，Seconds_Behind_Master 反而变大？
常见错觉是“压缩=更快”，实际它只减少字节量，不缩短单次网络 RTT，还引入解压开销。若配置不当，反而拖慢从库同步速度。
- 从库
max_allowed_packet小于解压后日志包大小 → 连接静默断开，错误日志里只有Lost connection to MySQL server during query，不会提示压缩相关 - 建议值：按主库典型事务 binlog 大小 × 1.5 设定，例如主库最大事务生成 8MB binlog，则从库设
SET GLOBAL max_allowed_packet = 12582912 - 压缩对高熵数据无效甚至膨胀：已 base64 的字段、UUID、加密 token 等，
COMPRESS()后可能变大 3–5%，这类数据多时压缩率会跌到0.9+（查SHOW STATUS LIKE 'Compression%'确认） - 监控关键指标：
Compression_rate持续低于0.25，说明收益极小，应关闭压缩或改用业务层过滤（如只同步核心表）
压缩只作用于复制流量，不影响客户端连接
很多人混淆「复制压缩」和「客户端连接压缩」，以为配了 COMPRESSION_ALGORITHM 就自动给所有应用连上也压缩。不是这样。
-
COMPRESSION_ALGORITHM仅控制 IO Thread 从主库拉取 binlog 的链路，与应用连从库查数据完全无关 - 应用要压缩结果集，得单独配置：JDBC 加
&useCompression=true，pymysql 传compress=True，mysql 命令行用--compress - 两类压缩互不干扰，但共用同一台从库的 CPU —— 若同时开启且并发高，
mysqld的 %CPU 可能飙到 90%，此时需限制slave_parallel_workers或降级压缩等级 - 真正省带宽的是复制链路；客户端压缩只影响应用到从库这最后一跳，对异地灾备整体带宽占用贡献很小
压缩 + 半同步 + 心跳调优，三者必须协同
单纯开压缩不能解决异地灾备的抖动中断问题。公网链路不稳定时，IO Thread 容易假死，导致 Seconds_Behind_Master 突增，甚至主从失联。
- 必须配心跳：
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10.0（单位秒），避免网络短暂抖动触发重连风暴 - 必须启半同步：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'，并设rpl_semi_sync_master_enabled = ON，防止主库提交后因从库未收到就返回成功 - 压缩与半同步不冲突，但要注意：半同步等待时间（
rpl_semi_sync_master_timeout）要大于压缩 + 网络 RTT 的总耗时，否则容易超时退化为异步 - 真实案例：北京→广州链路平均 RTT 50ms，zstd 压缩平均耗时 8ms，建议
rpl_semi_sync_master_timeout至少设为1000（1 秒），留足余量
压缩不是银弹，它只解决“字节数”问题；延迟、抖动、可靠性得靠心跳、半同步、监控告警一起兜底。线上压测时，务必用真实 binlog 流量跑 24 小时，看 Compression_rate 和 Seconds_Behind_Master 是否稳定在预期区间。
