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<br>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，否则容易混入不可移植的哈希值或插件信息
压缩不是万能的，真正影响备份体积的是你导出了什么，而不是怎么压缩它。
