mysqldump 或 mysqlpump 流式压缩直传 S3/OSS 需管道 gzip -c 并确保云 CLI 支持 stdin（如 aws s3 cp -、ossutil cp -），必须加 --single-transaction 保证一致性，MySQL 8.0+ 用 mysqlpump 时需显式设 --set-gtid-purged=OFF，避免 ERROR 2013 应优化查询而非仅调超时，恢复时须解压后导入，不可直接 source 远程压缩包。
mysqldump 直接管道到 aws s3 cp
能，但得绕过本地磁盘——关键是让 mysqldump 输出直接进 aws s3 cp - s3://bucket/path.sql.gz 的 stdin，中间不落地。这要求目标云 CLI 支持从标准输入读取（aws s3 cp - 支持，ossutil cp - 也支持，但需确认版本）。
常见错误是漏掉 gzip 压缩环节：数据库导出文本体积大，不压缩上传慢、费用高，且可能触发 OSS/S3 单请求超时（尤其百 MB+）。必须用 gzip -c 管道衔接。
mysqldump --single-transaction --routines --triggers db_name | gzip -c | aws s3 cp - s3://my-bucket/backups/db_$(date +%Y%m%d_%H%M%S).sql.gz- 如果用阿里云 OSS：
mysqldump ... | gzip -c | ossutil cp - oss://my-bucket/backups/...（注意 ossutil v2.0+ 才支持-读 stdin） - 务必加
--single-transaction，否则并发写入可能导致备份不一致；--skip-lock-tables不够安全，别用
MySQL 8.0+ 使用 mysqlpump 替代 mysqldump 流式导出
mysqlpump 原生支持并行导出和更细粒度控制，但默认不压缩、不直传云存储——它只是把输出扔到 stdout，后续管道逻辑和 mysqldump 一样。优势在于：对大库分表导出更快，且能跳过某些对象（比如只导数据不导视图）。
容易踩的坑是参数名差异：mysqlpump 用 --exclude-databases，而 mysqldump 是 --ignore-database；流式场景下若混用会静默失败。
- 导出单库并压缩上传：
mysqlpump --single-transaction --set-gtid-purged=OFF mydb | gzip -c | aws s3 cp - s3://b/mydb_$(date -Iseconds).sql.gz -
--set-gtid-purged=OFF必须显式指定，否则 MySQL 8.0 默认开启，导致输出含 GTID 语句，在非 GTID 环境恢复时报错ERROR 1840 (HY000) - 不支持
--routines和--triggers同时启用（会报错），要导存储过程得单独处理
遇到 ERROR 2013 (HY000): Lost connection 报什么？
这是流式备份最常中断的错误，根本原因不是网络抖动，而是 MySQL 服务端主动断开：默认 wait_timeout 是 28800 秒（8 小时），但实际触发阈值常更低——因为 mysqldump 在 dump 大表时，若单个查询执行时间超过 net_read_timeout（默认30秒），连接就被 kill。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
解决方法不是调大 timeout（治标），而是让 dump 过程更“匀速”：拆分大表、限制 chunk、加索引优化查询路径。
- 对超千万行表，用
--where="id BETWEEN 1 AND 100000"分段导出再合并（需自己拼接） - 用
--skip-extended-insert降低单行长度，减少网络缓冲区压力（但增大文件体积） - 检查
max_allowed_packet是否足够，太小会导致大 BLOB 字段截断，后续解压还原时报语法错误
OSS/S3 上传后无法直接 restore 怎么办？
不是权限或路径问题，而是你忘了——云存储上存的是压缩包，mysql 客户端不能直接读 .gz 文件。必须先下载解压，或用管道解压后喂给 mysql。但流式恢复比备份更难，因为没法边下载边解压边导入（S3/OSS 不支持随机 seek）。
所以备份时就该决定恢复路径：如果追求可立即恢复，备份文件应保留为未压缩 SQL（体积大但省事）；如果选压缩，就得接受恢复前必走一步 aws s3 cp s3://... - | gunzip | mysql db_name。
- 验证备份有效性：上传后立刻跑一次
aws s3 cp s3://b/f.sql.gz - | gunzip | head -20，看前20行是不是合法 SQL - 别用
mysql -e "source /path/to/file.sql"恢复远程文件——source只认本地路径，且不支持管道 - OSS 的
ossutil若提示Connection reset by peer，大概率是没开 HTTP 长连接，加--connect-timeout=60参数
事情说清了就结束
