mysqldump 本身不提供压缩等级参数，压缩等级由管道后接的 gzip、zstd 或 xz 等工具控制；常见错误是混淆 --compress 协议压缩与文件压缩，实际备份体积取决于后续压缩命令的参数。
mysqldump 压缩等级由谁控制？不是它自己
直接说结论：mysqldump 本身不提供压缩等级参数，它只输出 sql 文本。所谓“备份压缩等级”，实际是靠管道后面接的 gzip、zstd 或 xz 决定的。
常见错误现象：在 mysqldump 命令里加 --compress 或 -C，结果发现文件没变小，甚至更大——那只是启用客户端/服务端压缩协议，和备份文件体积完全无关。
-
mysqldump -u root db | gzip -9 > backup.sql.gz：用gzip最高压缩比，慢但省空间 -
mysqldump -u root db | zstd -19 > backup.sql.zst：zstd级别 19，压缩率接近xz，解压快得多 -
mysqldump -u root db | xz -T0 > backup.sql.xz：多线程xz，压缩最强，但 CPU 和内存吃紧，恢复时也慢
勒索场景下，压缩等级选高还是低？看恢复优先级
防勒索不是拼谁的备份最小，而是拼“被加密后能否快速拉起一套可用库”。高压缩率（如 xz -9）让单个文件更难被篡改，但恢复时解压耗时长、失败率略高；低压缩率（如 gzip -1）几乎不增加 CPU 开销，秒级解压，适合 RTO 小于 5 分钟的场景。
真实使用场景：线上主库每日全量 + binlog 归档，备份文件要能被运维半夜手动恢复——这时候宁可多占 30% 空间，也要确保 zcat backup.sql.gz | mysql 不卡住、不报 Out of memory。
- 生产环境推荐
zstd -12：压缩率比gzip -9高约 18%，解压速度是xz的 4 倍以上 - 避免用
gzip -0：看似快，但备份体积暴增，网络传输和磁盘写入反而成瓶颈 - 不要对已加密的备份再套一层压缩：AES 加密后数据熵极高，再压基本无效，纯属浪费 CPU
MySQL 8.0+ 备份链路中，zstd 支持需手动确认
mysqldump 从 MySQL 8.0.22 起才原生支持 --compress-output=zstd，但默认不启用，且依赖客户端 libzstd 版本 ≥ 1.3.0。很多 CentOS 7 / Ubuntu 18.04 自带的 mysql-client 包仍绑着旧版库，运行时报错 Unknown compression algorithm 'zstd'。
验证方式很简单：
mysqldump --help | grep compress
如果输出里没有 zstd 字样，说明当前客户端不支持。此时别折腾编译，直接走管道更稳：
- 确认系统已装
zstd：which zstd - 用
mysqldump ... | zstd -T0 -12 > backup.zst，-T0表示自动用满 CPU 核心 - 注意：MySQL 官方 Docker 镜像（如
mysql:8.0）不含zstd，必须自定义镜像或挂载宿主机二进制
备份脚本里硬编码 -9 很危险
把 gzip -9 写死在定时任务里，等于给备份过程埋了性能雷。高峰期跑全库 dump + 最高压缩，可能吃光 I/O 带宽或触发 cgroup 内存限制，导致 mysqldump 被 OOM kill，备份静默失败。
真正该做的，是按时段/负载动态调参：
- 凌晨 2–4 点：用
zstd -15，机器空闲，压得狠点没问题 - 工作日 9–18 点：降为
zstd -7，压缩率只比 -15 低 6%，但 CPU 占用减半 - 检查
LOAD DATA INFILE类大表存在时，跳过压缩直出 SQL，避免管道阻塞——这类表通常单独导出
最易被忽略的一点：压缩进程崩溃时，管道上游 mysqldump 默认会收到 SIGPIPE 并退出，但错误码常被忽略。务必在脚本里加 set -o pipefail，否则 backup.sql.gz 可能是截断的半成品，而 cron 日志显示“成功”。
