Go 批量导出如何避免结果归并拖垮内存：分段文件、排序归并与断点续写

订单导出从几万行涨到几百万行后，最先出问题的往往不是数据库，而是 Go 进程里的结果切片：查询还没结束，内存已经持续上涨，最后不是被系统杀掉，就是因为频繁 GC 让导出速度越来越慢。解决办法不是把机器内存继续加大，而是让中间结果尽早落到分段文件，最后只用很小的缓冲区完成有序归并。

一次性聚合为什么会在大数据量下失控

最直观的写法是边查边 append，等所有行准备好后再排序和写 CSV。它把三种内存同时叠在一起：数据库扫描缓冲、全量记录切片、排序期间的临时开销。行结构里如果还有字符串和 JSON 字段，真实占用会比 CSV 文本大得多。

可以先观察两个信号：导出行数增长时 RSS 是否近似线性上升，GC pause 是否在后半程明显变长。如果是，继续调整批量查询大小只能延后崩溃时间，不能改变峰值内存模型。

先把结果切成可管理的分段文件

假设每个分段最多 10 万行。读取数据库分页结果时，只保留当前段；达到上限后先按导出键排序，再写入临时文件并关闭文件句柄。文件名带上序号，例如 part-00017.tmp，不要用时间戳作为唯一顺序依据。

const partRows = 100_000

type Row struct {
    OrderID int64
    Created time.Time
    Amount  int64
}

func flushPart(dir string, no int, rows []Row) (string, error) {
    sort.Slice(rows, func(i, j int) bool {
        if rows[i].Created.Equal(rows[j].Created) {
            return rows[i].OrderID 

排序键必须稳定。示例里用 Created 加 OrderID 做复合键，这样相同时间的记录不会在不同分段之间出现随机顺序。写完后再计算文件大小和校验值，写入 manifest，避免把半截文件误当成可归并输入。

分段文件不是最终结果：用 k 路归并控制内存

如果有 40 个分段，不能再把它们读进一个大切片排序。每个文件只读取一行，把这一行放入小顶堆；弹出最小值后，再从它所属的文件读取下一行。内存里始终只有“文件数 + 一点缓冲”的数据。

Go 的 container/heap 很适合做这个结构。堆元素保存当前行、来源文件和序号；比较函数必须与分段排序使用相同的 Created、OrderID 规则，否则归并后的总文件会失序。

把失败恢复设计成清单，而不是猜文件名

导出任务至少需要保存任务 ID、查询范围、排序版本、分段序号、文件大小、校验值和状态。状态建议区分 writing、ready、merged，只有 ready 的分段才允许进入最后归并。

进程在写文件时退出，重启后先扫描 manifest：writing 状态直接删除临时文件并重做；ready 状态先校验大小与摘要；merged 状态不再重复写入最终文件。这里不要仅凭“文件存在”判断成功，机器断电时文件可能存在但尾部没有完整刷新。

上线前验收三个数字

第一是峰值 RSS：用相同数据量把导出从 50 万行逐步加到 500 万行，峰值应接近分段大小和归并缓冲的上限，而不是随总行数线性增长。第二是最终文件顺序：抽取相邻边界行，确认 Created、OrderID 单调不降。第三是恢复耗时：在生成第 N 个分段和最终归并阶段各注入一次进程退出，重启后不应重复消费已经标记 ready 的分段。

分段大小也不是越大越好。太小会产生大量文件和更长的归并堆；太大则会让单段排序占用更多内存。可以先从 5 万到 10 万行压测，再根据单行大小、磁盘吞吐和允许的恢复时间调整。

常见问题

为什么不直接使用数据库的 ORDER BY 导出？

数据库排序仍可能产生磁盘临时空间和长事务压力，且跨多个来源或需要二次加工时不够灵活。分段归并适合把排序压力拆开，并把恢复边界掌握在应用侧。

临时文件放本地磁盘安全吗？

要看任务是否允许迁移。单机任务可以放独立临时目录并设置清理策略；多实例任务应使用共享存储或把任务固定到同一实例，同时记录文件校验值，避免节点切换后找不到分段。

导出过程中数据发生变化怎么办？

需要明确一致性边界，例如固定时间范围、使用快照读，或在任务表中记录最大 ID。不要让分页条件依赖会变化的 offset，否则插入和删除会造成漏行或重复行。

让导出从“拼内存”变成“管理边界”

大批量导出的核心改造是把全量结果拆成一组可验证的中间产物：当前段负责有限内存排序，ready 段负责可靠保存，归并阶段负责稳定输出，manifest 负责恢复判断。这样总行数继续增长时，内存、失败重试和排查路径仍然有清楚的上限。