压缩 MySQL 备份应优先用管道实时压缩（如 mysqldump | pigz），配合 --skip-comments 等参数减原始体积，推荐 zstd（-T0 -12）平衡速度与压缩率，超大库按表分卷并定期清理旧备份。
压缩 MySQL 备份文件能显著减少存储占用和传输时间，关键在于选择合适工具、参数和时机，而非盲目追求高压缩率。
用 gzip 或 pigz 加速压缩
mysqldump 默认不压缩，需配合管道实时压缩。gzip 是通用选择，pigz（并行 gzip）在多核服务器上更快：
-
基础命令：
mysqldump -u user -p database | gzip >
backup.sql.gz
-
提速建议：安装 pigz 后直接替换 gzip，无需改脚本——
mysqldump ... | pigz > backup.sql.gz - 注意点：避免先生成大 SQL 文件再压缩，既占磁盘又耗时；管道方式内存友好，适合大库
调整 mysqldump 参数减小原始体积
压缩前缩小 SQL 文件本身更高效。以下参数可降低输出大小约20%–40%：
- --skip-extended-insert：禁用批量 INSERT，但会增大文件——通常 不推荐，除非需单行调试
- --skip-comments：去掉注释（如版本、时间戳），精简冗余文本
- --skip-triggers --skip-routines --skip-events：若备份仅用于数据恢复，且逻辑结构已单独管理，可跳过这些对象
- --single-transaction：对 InnoDB 保证一致性，比 --lock-all-tables 更轻量，减少锁等待和临时膨胀
考虑 zstd 或 lz4 获取更高性价比
gzip 压缩率中等、速度尚可；zstd（Facebook 开发）在压缩比与速度间更均衡，lz4 则极致追求速度：
-
zstd 推荐参数：
mysqldump ... | zstd -T0 -12 > backup.sql.zst（-T0 自动用满 CPU，-12 平衡速度与压缩率） -
lz4 适用场景：备份频次高、磁盘 IO 敏感时，
| lz4 > backup.sql.lz4压缩/解压均极快，压缩率略低于 gzip -
验证兼容性：确保目标环境装有对应解压工具（如 zstd、lz4），生产脚本中加入
command -v zstd检查
定期清理+分卷压缩应对超大库
单文件超 10GB 时，压缩易失败、恢复难、校验慢。建议拆分处理：
- 按表分卷：用脚本遍历表名，逐个 mysqldump + 压缩，文件名含表名和日期，便于定位和并行恢复
-
按大小分卷：用
split -b 2G分割已压缩文件（如 .zst），但需配套记录分卷顺序，不如按表清晰 -
自动清理旧备份：用 find 删除 7 天前的 .zst 文件：
find /backup -name "*.zst" -mtime +7 -delete
