直接用 mysqldump | gzip 管道压缩最稳妥省空间；先生成 .sql 再 gzip 会因临时文件占双倍磁盘空间而易失败，且 i/o 高；管道流式处理不占磁盘、内存峰值低，gzip 压缩率通常 70%–85%，但含大量 blob 或加密字段时收益骤降。
直接用 mysqldump | gzip 管道压缩，是最稳妥、最省空间的做法；别先写 .sql 再 gzip，大库容易磁盘满或卡死。
为什么不能先 mysqldump 再 gzip？
因为中间会生成一个和数据库体积几乎等大的纯 SQL 文件。比如 50GB 的库，dump 出来就是 50GB 的 backup.sql，再 gzip 又要额外 50GB 临时空间——磁盘稍紧就失败，且 I/O 拉满拖慢备份速度。
- 管道压缩（
mysqldump ... | gzip > backup.sql.gz）全程内存流式处理，峰值内存只取决于单次网络包/事务大小，不占磁盘临时空间 - gzip 对 SQL 文本压缩率通常在 70%–85%，但若表里大量
BLOB或加密字段，压缩收益会骤降，此时应优先检查是否真需要备份这些字段 - 恢复时也别解压到磁盘：用
zcat backup.sql.gz | mysql -u root -p db_name直接导入，避免多一次落盘
mysqldump 哪些参数能减小原始输出体积？
压缩前让 dump 输出更“干净”，比单纯提高压缩级别更有效——尤其对含大量注释、空行、版本兼容标记的库。
-
--skip-comments：去掉所有/*!40101 SET ... */类条件注释（注意：跨 MySQL 大版本迁移时可能影响兼容性） -
--compact：删掉默认的头尾说明、空行、分隔符，输出更紧凑 -
--no-tablespaces：跳过表空间定义语句（适用于非独立表空间部署） - 不要加
--no-create-info或--no-data：这会让备份失去完整语义，不是“压缩”，是“残缺导出”
大库（>100GB）该选 mysqldump 还是 mydumper？
mysqldump 是单线程 dump，哪怕配了 pigz 并行压缩，源头仍是瓶颈；mydumper 才是为大库设计的并行方案。
-
mydumper -u root -p pass -B db -o /backup/ --compress：自动按表拆分 + zlib 压缩，每个.sql文件独立压缩，支持 rsync 增量同步 - 它不保证视图/存储过程的事务一致性，需额外加
--triggers --routines - 压缩级别固定（zlib level 6），如需更高压缩率，可改用
mydumper ... | pigz -9 > full_backup.tar.gz，但会失去按表恢复能力 - 别指望
mysqldump --compress：这个参数是客户端和服务端之间传输压缩，**不压缩输出内容本身**，和文件压缩无关
压缩备份后恢复失败常见原因
不是压缩本身出错，而是操作链中某个环节破坏了流完整性。
- 用
tar -zcf包一层.sql.gz：解压后得到的是 tar 包，不是 SQL 流，mysql会报错ERROR 1064——直接用.sql.gz格式，别套壳 - 密码明文写在脚本里：被
ps aux看见，也易被日志捕获；应走~/.my.cnf配置文件，并设chmod 600 ~/.my.cnf - 没验证备份有效性：压缩成功 ≠ 可恢复。定期跑
zcat backup.sql.gz | head -n 100 | mysql -u test -D test测试前几行语法
真正省空间的关键不在“压得多狠”，而在“导出得干净”+“流式不落地”。压缩只是最后一环，前面参数选错，再快的 pigz 也救不回冗余的 20% 体积。
