mysqldump + zstd 压缩必须管道化，因其--compress参数仅压缩网络传输层（zlib），不影响输出文件体积；正确方式是mysqldump | zstd -T0 > backup.sql.zst，避免临时文件、节省空间且解压快5倍。
mysqldump + zstd 压缩必须管道化，不能只靠 --compress
mysqldump 本身不支持 zstd，它的 --compress 参数仅启用 MySQL 协议层的 zlib 压缩（作用于客户端与服务端之间的网络传输），对输出文件体积毫无影响。你看到的备份文件大，正是因为 dump 出来的是明文 SQL，再大也得原样写入磁盘。
正确做法是让 mysqldump 输出直接进 zstd 管道：
-
mysqldump -u root -p test_db | zstd -T0 > backup.sql.zst（-T0表示自动用满 CPU 核数） - 避免先写临时文件再压缩：既占双倍磁盘空间，又多一次 IO
- 若需保留可读性调试，加
--format=plain或用zstd -v查看压缩率反馈
xtrabackup 启用 zstd 需显式指定 --compress=zstd
Percona XtraBackup 8.0.30+ 原生支持 zstd，但默认不启用。不写 --compress=zstd 就是裸备份，哪怕装了 zstd 包也没用。
关键参数组合：
-
--compress=zstd：必须显式声明，否则走默认无压缩路径 -
--compress-threads=4：线程数建议设为物理核数，过高反而因调度开销降低吞吐 -
--compress-zstd-level=6：级别 6 是速度与压缩率的甜点区；1–3 太快但压缩率低，12+ 压缩率提升有限却显著拖慢备份 - 注意：
--stream=xbstream和--compress=zstd可共存，但流式输出必须重定向到 .xbstream 文件，不能直接 stdout
zstd 比 gzip 节省近一半空间，但恢复时要装对应解压工具
实测 5GB 数据库：
-
mysqldump | gzip -9→ ~2.1GB -
mysqldump | zstd -T0 -12→ ~1.2GB（压缩率高 43%，且解压快 5 倍） -
xtrabackup --compress=zstd -6→ 比 lz4 小 28%，比裸备份小 62%
陷阱在于恢复环节：
- 用
zstd -d backup.sql.zst | mysql -u root -p恢复，必须确保目标机器装了zstd命令行工具 - XtraBackup 恢复时若提示
unknown compression algorithm，说明备份节点用了 zstd，但恢复节点没装zstd库或版本太旧（要求 ≥1.4.0） - 别用
zstd -d解压 xbstream 流——它需要xtrabackup --decompress配合--compress=zstd才能识别格式
Binlog 和复制链路也能用 zstd，但版本和权限要卡死
MySQL 8.0.20+ 的 binlog 压缩、8.0.21+ 的复制压缩，都只认 zstd，不支持其他算法。但启用前必须确认：
- 主库
binlog_transaction_compression=ON，且 MySQL 用户有SUPER或SYSTEM_VARIABLES_ADMIN权限 - 从库执行
CHANGE MASTER TO MASTER_COMPRESSION_ALGORITHM='zstd'，不是compress=zstd（那是 DSN 语法） - 复制压缩只对事务事件生效，DDL、heartbeat event 等不压缩；若 binlog 中混杂大量非事务语句，实际带宽节省会打折扣
- 监控
Com_binlog_transaction_compression_stats状态变量，看真实压缩率是否达标（低于 30% 建议调高binlog_transaction_compression_level）
zstd 的优势不在理论峰值，而在稳定场景下的综合性价比——压缩率够高、解压够快、CPU 占用可控。真正卡住落地的，往往是恢复链路上少装了一个 zstd 包，或者备份脚本里漏写了管道符。
