实测比查文档更可靠，因压缩受cpu、内核、mysql版本及数据熵值影响大，结果可能偏差超30%；必须同步评估压缩耗时、解压耗时、文件大小三指标；zstd -t0 -12 是生产最稳妥起点；mysqldump体积大属正常，因含sql元信息；减体需外部压缩；加密必须在压缩之后。
直接在目标服务器上跑一次实测，比查文档、看别人 benchmark 更可靠。因为压缩耗时和体积受 CPU 型号、内核版本、MySQL 客户端版本、数据熵值（比如是否含加密字段）影响极大，同一套参数在不同机器上结果可能差 30% 以上。
必须实测的三个核心指标
评估不能只看“压缩率”，得同步盯住：压缩耗时、解压耗时、最终文件大小。这三个数字缺一不可：
- 压缩耗时决定你能否在备份窗口内完成（比如凌晨 2–4 点）
- 解压耗时直接影响恢复速度——某次故障中
xz -d解压 1.2GB 文件用了 6 分 42 秒，而zstd -d只要 11 秒 - 最终文件大小影响磁盘和网络传输成本，但别迷信“越小越好”：比如
gzip -0虽快，但体积暴增，后续写入和传输反而拖慢总耗时
zstd -T0 -12 是生产环境最稳妥的起点
别一上来就试 zstd -19 或 xz -9e。它们压缩率高，但代价明显：
-
zstd -19解压内存开销翻倍，某些低配 VPS 会报ZSTD_decompressStream: out of memory -
xz -9e单线程、解压极慢，且 MySQL 8.0+ 原生不支持，只能靠管道，恢复链路更脆弱 -
zstd -T0 -12自动用满 CPU 核数，压缩率比gzip -9高约 18%，解压速度是xz的 4 倍以上，实测兼容性也最好
mysqldump 输出体积比 data_length + index_length 大很多？正常
因为 mysqldump 输出的是 SQL 文本，不是二进制镜像。默认带建表语句、INSERT INTO ... VALUES () 前缀、字段名重复、单引号包裹字符串、字符集声明等，这些都会膨胀体积：
- 加
--skip-extended-insert会让每行只插一条，体积更大；保持默认--extended-insert是减体积的有效手段 -
--compress参数只压缩客户端与服务端之间的传输流，不影响最终生成的 SQL 文件大小 - 真正减体积，得靠外部压缩：比如
mysqldump ... | zstd -T0 -12 > backup.sql.zst
最容易被忽略的一点：加密必须在压缩之后做。先加密再压缩几乎无效——加密后的数据接近随机分布，zstd 或 gzip 压缩率会从 70% 掉到 10% 以下。所以脚本里顺序要是 mysqldump | zstd | gpg，而不是反过来。
