连续60天从自家鸡里导出几亿数据的实战复盘

最近这两个月，我总算折腾完了一个大项目——连续60天，每天从自己的服务器（俗称“鸡”）里往外导数据。这数据量级可不是开玩笑的，整整几亿条记录。今天我就来复盘一下这段“苦力”时光，聊聊我是怎么搞定这个庞然大物的，以及中间踩过的那些坑。

起因：数据量太大了

一开始也没想那么多，业务需求需要把历史数据全量迁移出来做分析。看着数据库里那几亿行的数据量，我第一反应是：“直接导出不就行了？”结果现实狠狠地打了我一巴掌。

普通的 mysqldump 或者直接 SELECT INTO OUTFILE，在数据量小的时候确实香，但面对几亿数据，简直就是灾难。服务器负载直接飙升，磁盘IO被打满，连正常的业务请求都开始超时。看来，“大力出奇迹”在这里行不通，得讲策略。

第一步：解决“锁”的问题

最开始尝试导出时，最头疼的就是锁表。一旦锁住，业务就得停摆，这是绝对不能接受的。

数据库锁表会导致业务停摆，需避免长事务

后来我改用了主从架构的思路。既然主库忙不过来，那就搭建一个只读从库，或者干脆在业务低峰期对主库加读锁进行快照备份。在这个环节，我更倾向于使用 pt-archiver 这类工具，它可以分批、分片地处理数据，避免长事务和大锁。

第二步：分片才是王道

几亿数据一次性导出，IO压力太大了。我把目光投向了“分片处理”。

简单来说，就是按照主键ID或者时间字段，把大表切成无数个小块。比如每次只导出10万条，或者按天、按月导出。

这样做的好处有两个：

1. 可控性强：脚本挂了、中断了，只需要重跑当前这一小片数据就行，不用从头再来。
2. 对服务器压力平摊：磁盘读写变成了涓涓细流，不会瞬间把CPU和IO耗尽。

第三步：压缩传输，省带宽就是省钱

数据导出到了本地，还得往外搬运。如果是明文传输，那带宽成本得让人肉疼。

我的方案是“流式压缩”。边导出边通过管道传给 gzip 或者 pigz（多核压缩版）。

边导出边压缩，节省带宽与存储空间

举个例子：

mysql -e "SELECT * FROM table WHERE id > 10000 AND id <= 20000" | gzip > data_20231001.sql.gz

这样输出出来的文件大小通常只有原来的1/10甚至更小，传输速度快了九成不止，存储空间也省了一大截。

第四步：网络与磁盘的持久战

这一步其实最考验服务器的稳定性。整整60天，机器得24小时连轴转。

在这里我遇到了几个坑：

• 磁盘写满：有时候压缩脚本没跑好，临时文件堆积导致磁盘爆满，监控报警狂响。所以一定要做好磁盘监控，或者设置定期清理机制。

• 网络波动：跨境传输网络不稳定，大文件传了一半断了。后来我用了 rsync 的断点续传功能，配合脚本做校验，才算稳住阵脚。

• CPU过热：持续的高压缩比运算导致CPU温度一直居高不下。如果是普通的廉价VPS，可能会触发商家的流控或者甚至把机器跑挂。建议低配机器优先使用低优先级命令（如 nice 和 ionice），别把系统资源吃光了。

总结与建议

折腾完这一票，我最大的感悟就是：在大数据面前，策略比硬件更关键。

如果你也面临类似的需求，不管是迁移还是备份，记住这三点：

1. 不要试图一次性吃完大象，分片处理是必须的。
2. 尽量减少对生产环境的影响，利用从库或者低峰期操作。
3. 善用压缩和断点续传工具，降本增效。

虽然过程很折磨人，但看着那整齐划一的备份文件躺在存储里，还是有一种莫名的成就感。希望我的这些经验能帮到正在“搬砖”的你，少走点弯路！