应优先选解压快、压缩率适中的zstd-T0-12：压缩率比gzip-9高约18%，解压速度是xz的4倍以上，且支持多线程，实测1.2GB文件解压仅11秒，显著缩短RTO。
压缩算法选型要看三个硬指标：压缩耗时、解压耗时、最终体积
评估不是看“谁更先进”，而是看这三个数字在你真实环境里跑出来多少。比如同样 10GB 的 mysqldump 输出，gzip -9 可能压到 2.8GB 耗时 4 分半，zstd -12 压到 2.3GB 耗时 3 分 15 秒，而 lz4 压到 4.7GB 只要 38 秒——哪个更适合你，取决于你的恢复 SLA 和磁盘预算。
关键点在于：必须在目标服务器上实测，不能照搬别人的数据。香港 VPS 上 zstd -T0 -12 表现好，不代表你那台 2 核 CentOS 7 的旧物理机也一样；MySQL 8.0.22+ 客户端才支持 --compress-output=zstd，但多数线上环境仍是手动管道压缩，别被参数名误导。
为什么 gzip -9 在备份场景中常是“伪最优”
gzip -9 看似压缩率最高，但实际在 MySQL 备份链路中容易暴露短板：
- 压缩过程 CPU 持续占满，可能拖慢同机其他服务（比如主库正在写 binlog）
- 解压速度一般，
zcat backup.sql.gz | mysql在大文件下易触发 OOM，尤其当 buffer_pool 不足时 - 不支持多线程，无法利用现代服务器的多核优势；换成
pigz -9可提速近 3 倍，但压缩率不变 - 对已加密或高熵数据（如 AES 加密后的备份）再压基本无效，反而白耗 CPU
zstd 参数调优不能只看 -19，-T0 和 -12 才是生产主力
zstd 的压缩级别从 1 到 22，但生产环境几乎不用极端值：
-
zstd -19压缩率接近xz -9，但解压内存开销翻倍，某些低配 VPS 解压时报ZSTD_decompressStream: out of memory -
zstd -T0 -12是平衡点：自动用满 CPU 核数，压缩率比gzip -9高约 18%，解压速度却是xz的 4 倍以上 - MySQL 8.0+ 若用原生
--compress-output=zstd，必须确认客户端libzstd≥ 1.3.0，否则报错Unknown compression algorithm 'zstd' - 脚本中务必加校验：
command -v zstd || { echo "zstd not found"; exit 1; }
真正影响恢复速度的，往往是解压环节而非压缩环节
勒索攻击后最致命的不是备份文件大，而是恢复卡在解压阶段。某次真实故障中，运维半夜拉起备份，xz -d 解压一个 1.2GB 文件用了 6 分 42 秒，期间 MySQL 连接超时、监控告警雪崩；换 zstd -d 同文件仅 11 秒。
所以别只盯着压缩率。如果你的 RTO 要求 zstd -T0 -12 或 lz4 更靠谱；如果备份是冷归档、十年一用，才考虑 xz -9e。另外，gzip -0 看似快，但备份体积暴增，后续网络传输和磁盘写入反而成瓶颈，实际总耗时未必少。
