用 mysqldump | gzip 流式压缩可避免双份磁盘占用、减少 I/O、防止中间文件残留；需加 --single-transaction、--routines、--triggers 等参数保障一致性与完整性，密码交互输入，使用绝对路径并确认写权限。
直接用 mysqldump 管道接 gzip，是最简单、最省磁盘、最不容易出错的压缩方式。别先生成大 SQL 文件再压缩——那等于多写一遍磁盘，还可能因空间不足失败。
为什么必须用管道流式压缩，而不是先 dump 再 gzip？
备份大库时，mysqldump 输出可能达几十 GB。如果先写成 backup.sql，再跑 gzip backup.sql，会：
- 占用双份磁盘空间（原始 SQL + 压缩包），极易触发 No space left on device
- 多一次 I/O，耗时翻倍
- 中间文件若没清理干净，后续脚本可能误读旧文件
流式压缩全程内存/管道处理，输出即压缩，落地只有 .sql.gz 一个文件
mysqldump | gzip 的实际命令写法和参数注意点
基础命令没问题，但生产环境必须加关键参数，否则可能丢数据或卡死：
mysqldump -u root -p --single-transaction --routines --triggers database_name | gzip > backup_$(date +\%Y\%m\%d).sql.gz-
--single-transaction：对 InnoDB 表保证一致性快照，不锁表（MyISAM 不支持，需改用--lock-all-tables） -
--routines和--triggers：默认不导出存储过程和触发器，漏了恢复就缺功能 - 密码不要写在命令行里（
-p123456），会被ps看见；用-p让终端交互输入 - gzip 默认压缩级别是 6，想更快可加
-1（速度优先），想更小可加-9（但 CPU 升高明显）
恢复时别漏掉解压环节，常见错误现象
直接 mysql -u root -p db 会报错：<code>ERROR 1064 (42000) —— 因为 .gz 是二进制压缩流，不是 SQL 文本。
正确恢复方式只有两种：
- 解压后导入：
gunzip - 或分两步：
gunzip backup.sql.gz（生成backup.sql），再mysql -u root -p db
注意：gunzip 默认解压完删原 .gz 文件；如需保留，加 -k 参数（gunzip -k backup.sql.gz）
gzip 不行时换 bzip2 或 pigz，但别乱试
gzip 压缩率一般（通常 3–5 倍），如果磁盘特别紧张，可换 bzip2（压缩率更高，但慢 3–5 倍）或 pigz（gzip 的并行版，多核 CPU 下快很多）：
-
mysqldump ... | bzip2 > backup.sql.bz2→ 恢复用bunzip2 -
mysqldump ... | pigz -p 4 > backup.sql.gz（-p 4指定 4 线程）
但注意：pigz 不是所有系统默认安装，bzip2 在低配机器上可能卡住；除非实测有必要，否则坚持用原生 gzip 最稳。
真正容易被忽略的是权限和路径：备份脚本里用相对路径（比如 > backup.sql.gz），运行用户当前目录一变，文件就写到奇怪地方去了；务必用绝对路径，且确认目标目录 mysql 用户有写权限。
