核心是边导出边压缩、不落地明文：用mysqldump | gzip -c管道流式处理，避免生成中间明文文件；配合--single-transaction保证一致性，gzip -1/-3兼顾速度与压缩率，校验gunzip -t防损坏，传输需加密加固。
直接对巨型 SQL 导出文件做 gzip 压缩，核心不是“先导出再压缩”，而是边导出边压缩、不落地明文——既省带宽，又避风险。
用管道流式压缩，避免生成明文临时文件
mysqldump 输出是标准输出（stdout），天然适合接 gzip 流式处理。这样数据从数据库出来就立即压缩，全程不写入磁盘明文，杜绝泄露和磁盘满风险。
mysqldump -u root -p --single-transaction mydb | gzip -c > mydb_$(date +%F_%H%M).sql.gz
-
--single-transaction：保证 InnoDB 一致性快照，避免锁表中断； -
gzip -c：强制输出到 stdout（不重命名/覆盖），适配管道； -
> xxx.sql.gz：直接落盘为压缩包，零字节明文残留。
⚠️ 注意：别用
gzip > file.gz（缺-c），它会尝试改名，导致管道阻塞或失败。
压缩级别选平衡点，兼顾速度与体积
巨型 SQL（如百 MB 级报表库）导出时，CPU 和时间都敏感：
-
线上定时备份：用
gzip -1或gzip -3
→ 耗时减少 40%+，体积只比-6多 8%～12%，解压兼容性更好； -
一次性归档冷备：可跑
gzip -6（默认），压缩率约 70%～75%；
→ 避免-9：CPU 占满、耗时翻倍，体积仅多压 3%～5%，得不偿失。
弱网传输前再校验，防损坏包误传
压缩完成≠可用。弱网下若管道中断，可能产出空文件或截断包。务必加一步校验：
gunzip -t mydb_$(date +%F_%H%M).sql.gz && echo "✅ 校验通过" || echo "❌ 损坏，丢弃"
-
gunzip -t不解压，只检测完整性； - 建议在脚本中搭配
set -o pipefail，确保mysqldump | gzip任一环节失败，整个命令退出。
传输阶段继续加固：压缩后走加密通道
.sql.gz 文件虽已压缩，但仍是敏感数据。弱网环境更要防中间节点缓存、嗅探或误传：
- 上传必须走
rsync -e "ssh -o StrictHostKeyChecking=yes"，禁用弱 cipher； - 别用 HTTP/FTP 传
.sql.gz，哪怕加了 Basic Auth； - 若推到对象存储（如 S3），客户端加密（gpg/openssl） + 服务端加密（SSE-KMS）双开，不省这一步。
本质上，弱网传巨型 SQL，拼的不是单点技巧，而是「流式压缩→即时校验→加密传输」三步闭环。明文不出内存、不出磁盘、不出网络，带宽自然省下来，安全也兜住了。
