必须用 gzip -c，因为云 cli（如 aws s3 cp、ossutil cp）依赖 stdin 读取数据，而 gzip 默认压缩文件并改名，不输出到 stdout；只有 gzip -c 将压缩流输出至 stdout，才能被管道后续命令接收，否则上传文件为空或报 body cannot be empty 错误。
mysqldump + gzip + 云 CLI 管道直传为什么必须用 -c 和 -
因为云存储 CLI（如 aws s3 cp、ossutil cp）只接受标准输入（stdin）时，必须显式用 - 表示“从 stdin 读”，而 gzip 默认行为是压缩文件并改名（比如 backup.sql → backup.sql.gz），这会中断管道。只有 gzip -c 才把压缩流输出到 stdout，才能被后续命令接住。
常见错误现象：aws s3 cp - s3://bucket/backup.sql.gz 上传后文件大小为 0 字节，或报错 InvalidArgument: Body cannot be empty——基本就是 gzip 没加 -c，或者 mysqldump 因权限/锁表失败提前退出，导致管道前端无数据。
- 务必用
gzip -c，不能只写gzip - 云 CLI 命令末尾的
-不能省，这是 stdin 的唯一标识 - 阿里云
ossutilv2.0+ 才支持-，旧版本会静默失败；可用ossutil --version确认 - 如果用
gpg加密再上传，也要加--cipher-algo AES256 --compress-algo 1并确保目标端有对应私钥
MySQL 8.0+ 用 mysqlpump 直传时为什么必须加 --set-gtid-purged=OFF
MySQL 8.0 默认开启 GTID，mysqlpump 输出里会包含 SET @@GLOBAL.GTID_PURGED = 'xxx' 这类语句。但云存储只是存文件，不执行 SQL；等你后期恢复时，若目标实例没开 GTID 或 binlog_format 不是 ROW，就会报 ERROR 1840 (HY000)，直接中断导入。
而 mysqldump 在 8.0+ 默认也加 GTID 语句，但它提供 --set-gtid-purged=OFF 参数（和 mysqlpump 同名），但很多人只记得给 mysqlpump 加，忘了 mysqldump 也需要——尤其当备份用于跨环境恢复时。
mysqldump --single-transaction --set-gtid-purged=OFF mydb | gzip -c | aws s3 cp - s3://b/mydb_$(date +%s).sql.gz-
mysqlpump不支持--routines和--triggers同时启用，要导过程得单独跑一次--include-databases=mydb --routines -
--skip-triggers是mysqldump的参数，mysqlpump对应的是--exclude-triggers，混用会导致静默跳过对象
遇到 ERROR 2013 Lost connection 别只调 wait_timeout
这个错误看着像网络断连，实际 90% 是 MySQL 服务端主动 kill 掉了连接：不是因为整体备份超时，而是单个查询卡在大表上，超过了 net_read_timeout（默认仅 30 秒）。mysqldump 对大表用 SELECT 拉数据，如果这张表没主键或索引差，扫描太慢，就会触发它。
单纯调高 wait_timeout 没用，必须同步调 net_read_timeout，且要在 mysqldump 连接时生效——所以得加 --net-read-timeout=120 参数，而不是改 MySQL 配置文件（那会影响所有连接）。
- 加
--net-read-timeout=120 --net-write-timeout=120，数值按最大单表预估时间设 -
--quick必须加，强制逐行读取，避免客户端内存溢出导致卡死 - 如果表特别大（>10GB），考虑分表导出：
mysqldump --single-transaction mydb table1 table2 | gzip -c | ... - 别信“加大 max_allowed_packet 就能解决”，它只影响单条语句长度，不解决超时问题
恢复时为什么不能 source 远程 .sql.gz 链接
因为 mysql 客户端的 source 命令只读本地文件，且只认纯文本 SQL；它无法解压、无法发起 HTTP 请求、也无法解析 S3/OSS 的 presigned URL。试图 source https://.../backup.sql.gz 会直接报 ERROR 1064，甚至可能把二进制流当 SQL 执行，破坏数据库。
真正可行的路径只有一条：先下载 + 解压（或流式解压），再导入。自动化脚本里最容易漏的是校验环节——上传成功不等于文件完整，gzip 流中断会产生不可解压的损坏包。
- 上传后立刻校验：
aws s3 cp s3://b/backup.sql.gz - | gunzip -t（-表示输出到 stdout，gunzip -t只测试不落地） - 恢复时用：
aws s3 cp s3://b/backup.sql.gz - | gunzip | mysql -u root -p mydb，全程不落地 - 如果网络不稳定，优先用
rsync over SSH传本地文件，再本地解压导入，比直传云存储更可控 - 所有路径必须用绝对路径，
~/backups/在 cron 下常指向 root 家目录，而非当前用户
最易被忽略的是：管道中任一环节失败（比如 mysqldump 权限不足、gzip 内存溢出、云 CLI 认证过期），整个链路都会静默中断，只留下一个空文件或损坏包。必须在脚本里加 set -o pipefail，让任意命令非零退出就立即终止，并配合 gunzip -t 校验结果文件是否可解压。
