必须显式加大超时参数并同步调大MySQL服务端wait_timeout和interactive_timeout，按表分卷导出而非按大小切片，先dump再gzip压缩，用rsync断点续传。
mysqldump 分卷导出时怎么避免连接超时
默认 mysqldump 在导出超大库（比如几百 gb）时，tcp 连接容易被中间网络设备或 mysql 服务端主动断开，表现为报错 lost connection to mysql server during query 或直接中断。
关键不是加个 --single-transaction 就完事——它只管事务一致性，不保连接存活。
- 必须显式加大超时：在命令里加
--connect-timeout=3600、--net-read-timeout=7200、--net-write-timeout=7200 - MySQL 服务端也要同步调大：
wait_timeout和interactive_timeout建议设为28800（8 小时），否则客户端再怎么设也没用 - 如果走 SSH 隧道或跳板机，还得检查
ServerAliveInterval，建议在 SSH 命令中加-o ServerAliveInterval=60
按表分卷导出比按大小分卷更可靠
很多人想用 split -b 1G 对 mysqldump 输出流切片，但会破坏 SQL 文件结构（比如把一条 INSERT 拆到两个文件里），后续恢复直接报语法错误。
真正稳妥的做法是按表粒度拆分，每张表一个 .sql 文件，再统一压缩传输。
- 用
mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='your_db'" your_db获取表列表 - 对每个表执行
mysqldump --no-create-info --skip-triggers your_db <code>table_name>table_name.sql，避免单文件过大 - 加上
--skip-extended-insert可提升恢复时的容错性（单条失败不影响后续），但文件体积会变大，权衡取舍
gzip 压缩必须在写入磁盘前完成
边 dump 边 gzip（mysqldump ... | gzip > all.sql.gz）看似省空间，但一旦管道中断，整个压缩流就损坏，且无法 resume。超大库导出动辄几小时，风险太高。
- 推荐两步走：先
mysqldump ... > table.sql，再gzip -c table.sql > table.sql.gz - 用
pigz替代gzip（需提前安装），能利用多核，压缩速度可提升 3–5 倍 - 导出后立刻校验：
gzip -t table.sql.gz，别等传到远端才发现损坏
rsync 断点续传比 scp 更适合大文件传输
用 scp 传几十 GB 的 .sql.gz，失败就得重来；而 rsync 能基于块校验续传，实测节省大量重复时间。
- 命令示例：
rsync -avz --partial --progress your_db_*.sql.gz user@host:/backup/ -
--partial是关键，允许保留未传完的临时文件；--append-verify更严格（校验末尾块），但会略慢 - 如果目标磁盘空间紧张，先用
rsync --dry-run预估总大小，避免传到一半因空间不足失败
分卷、超时、压缩、传输这四步里，最容易被跳过的其实是服务端 wait_timeout 配置——它不报错，只是静默断连，然后你花半天排查才发现是它。
