mysqldump + gzip/pigz 是最直接的压缩备份方案，支持管道实时压缩、一致性保障与多核加速；需注意密码安全、中断防护、二进制数据转义及冗余内容过滤。
mysqldump + gzip 是最直接的压缩备份方案
MySQL 本身不提供内置压缩备份功能，mysqldump 输出的是纯 SQL 文本，天然适合管道压缩。直接在导出时用 gzip 压缩，能省去中间文件、减少磁盘 IO，也避免手动压缩遗漏。
典型命令：
mysqldump -u root -p --single-transaction mydb | gzip > mydb_$(date +%F).sql.gz
-
--single-transaction对 InnoDB 表保证一致性，且比--lock-all-tables影响小 - 不加
--databases时，mysqldump不包含CREATE DATABASE语句，还原前需手动建库 - 若密码写在命令行，会留痕于
history和ps输出，建议用配置文件~/.my.cnf管理凭据
使用 pigz 替代 gzip 提升多核压缩速度
默认 gzip 是单线程，大库（>10 GB）备份时 CPU 利用率低、耗时长。pigz 是 gzip 的并行实现，能自动利用全部 CPU 核心，实测压缩 20 GB SQL 文件可提速 3–4 倍。
安装与替换：
apt install pigz # Ubuntu/Debian
yum install pigz # CentOS/RHEL
只需把管道中的 gzip 换成 pigz：
mysqldump -u root -p mydb | pigz > mydb.sql.gz
-
pigz兼容gzip格式，用gunzip或zcat可直接解压，无需额外工具 - 若服务器内存紧张，可用
-p N限制线程数（如pigz -p 2），避免 swap 颠簸 - 注意：某些旧版系统预装的
gzip可能被硬链接到pigz，执行ls -l $(which gzip)可确认
避免 mysqldump 压缩后无法还原的三个坑
压缩本身不改变内容，但操作不当会导致 SQL 文件损坏或语义丢失，常见于以下场景：
- 终端断开或
Ctrl+C中断管道时，mysqldump进程可能未正常退出，导致.sql.gz文件不完整——建议加timeout控制最长运行时间：timeout 2h mysqldump ... | pigz > backup.sql.gz -
mysqldump默认不转义换行符和特殊字符，若表中含二进制数据（如BLOB字段），且未加--hex-blob，压缩后还原可能报错ERROR 1064；对含图片、PDF 等字段的表必须启用该选项 - 使用
zcat backup.sql.gz | mysql -u root -p还原时，若 SQL 文件含多个数据库或大量USE语句，而目标实例无对应库，会报错退出——应先用zcat backup.sql.gz | head -n 50查看结构，再决定是否分库还原
真正节省空间：跳过日志、临时表与统计信息
压缩只是“事后压缩”，更有效的方式是让 mysqldump 输出更小的原始 SQL。默认它会导出所有表、包括 information_schema、performance_schema 等系统库，以及注释、统计信息等冗余内容。
关键过滤参数：
- 用
--ignore-table=db.table_name排除已知无业务价值的大表（如日志表、监控快照表） - 加
--skip-comments和--skip-triggers（若确认不需要触发器逻辑）可减少 5–10% 体积 - 对只读从库备份，可加
--no-tablespaces（跳过CREATE TABLESPACE语句），尤其当主从表空间路径不一致时还能避免还原失败 - 绝对不要对
mysql系统库全量 dump —— 权限变更应走mysql.user导出或pt-show-grants，否则容易混入不可移植的哈希值或插件信息
压缩不是万能的，真正影响备份体积的是你导出了什么，而不是怎么压缩它。
