如何导出超大数据库而避免超时_分卷导出与压缩传输方案

mysqldump 分卷导出时怎么避免连接超时

处理几百GB的超大数据库导出时，一个常见的“拦路虎”就是连接超时。命令跑着跑着，突然就报错 lost connection to mysql server during query，或者干脆直接中断，让人措手不及。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

这里有个关键点需要厘清：很多人以为加上 --single-transaction 参数就万事大吉了。这个参数确实能保证导出数据的事务一致性，但它可管不了连接的死活。连接该断还是会断。

所以，真正的解决方案需要双管齐下：

• 客户端必须显式加大超时参数：在 mysqldump 命令里，直接加上 --connect-timeout=3600、--net-read-timeout=7200 和 --net-write-timeout=7200。这相当于告诉客户端程序：“耐心点，等久一点。”
• 服务端配置必须同步调整：光客户端有耐心没用，MySQL服务端自己也有个“耐心值”。需要登录数据库，将 wait_timeout 和 interactive_timeout 这两个参数调大，比如设为 28800（也就是8小时）。否则，服务端觉得连接空闲太久，还是会主动掐断。
• 别忘了中间链路：如果导出操作需要通过SSH隧道或者跳板机，那还得检查SSH连接的保活设置。建议在SSH命令中加入 -o ServerAliveInterval=60 参数，让连接保持活跃。

按表分卷导出比按大小分卷更可靠

解决了连接问题，接下来是分卷策略。一个很自然的想法是：用 split -b 1G 这样的工具，按固定大小对导出的SQL流进行切片。想法很美好，但现实很骨感——这么做很容易破坏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 table_name > table_name.sql 的命令。这样，每张表的数据都独立成文件，避免了单个文件过大的问题。
• 这里还有个细节：可以考虑加上 --skip-extended-insert 参数。它会将数据导出为多条独立的INSERT语句，而不是合并成一条。这样做的好处是，恢复时如果某条数据出错，不会影响后续数据的插入，容错性更好。当然，代价就是导出的文件体积会显著增大，需要根据实际情况权衡。

gzip 压缩必须在写入磁盘前完成

为了节省宝贵的磁盘空间，边导出边压缩（mysqldump ... | gzip > all.sql.gz）是个很诱人的方案。但这里有个隐藏的风险：管道（pipe）一旦因为任何原因中断，整个压缩数据流就可能损坏，而且无法从中断点恢复。对于需要运行数小时的超大库导出任务来说，这个风险太高了。

更推荐的流程是两步走，稳扎稳打：

• 第一步，先把数据完整地导出到纯文本的.sql文件：mysqldump ... > table.sql。
• 第二步，再对这个文件进行压缩：gzip -c table.sql > table.sql.gz。
• 想提升压缩速度？可以用 pigz 这个工具替代标准的 gzip（需要提前安装）。它能利用多核CPU进行并行压缩，速度提升3到5倍是常有的事。
• 压缩完成后，养成一个好习惯：立刻用 gzip -t table.sql.gz 命令校验一下压缩包的完整性。千万别等到文件传到远程备份服务器后才发现损坏，那就得全部重来一遍了。

rsync 断点续传比 scp 更适合大文件传输

最后一步，是把压缩好的数据文件传输到备份服务器。面对几十GB的庞然大物，常用的 scp 命令就显得力不从心了——一旦网络波动导致传输中断，就得从头开始。

这时候，rsync 的优势就凸显出来了。它支持断点续传，能够基于文件块进行校验，只传输发生变化的部分。实测下来，能为大文件传输节省大量重复时间。命令可以这样写：

• rsync -a vz --partial --progress your_db_*.sql.gz user@host:/backup/
• 这里的 --partial 参数是关键，它允许保留未传输完成的临时文件，下次传输时可以接着来。
• 如果对数据一致性要求极高，可以考虑加上 --append-verify 参数，它会校验文件末尾的数据块，但传输速度会稍微慢一点。
• 在开始传输前，如果目标磁盘空间紧张，先用 rsync --dry-run 模拟运行一下，预估总传输大小，避免传到一半因为空间不足而失败。

回顾一下，分卷、超时、压缩、传输，这四步环环相扣。其中，服务端的 wait_timeout 配置最容易被人忽略。它平时不声不响，一旦超时就静默断连，往往让人排查半天才恍然大悟。所以，下次遇到导出中断，不妨先从这里查起。