如何高效处理MongoDB百万级记录并实现低内存两表数据比对

你之前方案的核心问题从根上就错了，根本不是内存泄漏，是全量加载的设计必然导致OOM和性能问题：1.6M+1.46M条文档哪怕单条原始BSON只有500B，转成Java POJO/Map后算上对象头、引用指针、集合扩容预留空间，内存占用是原始数据的4~6倍，300w条数据轻松占满10G以上堆内存，GC停顿、锁竞争自然会把耗时拉得极高。
下面是经过生产验证的落地方案，内存占用稳定控制在百MB级，300w量级数据10分钟内就能跑完： #

方案1：有序流式双指针比对（优先选，单线程就够快，内存占用最低） #

核心逻辑是完全放弃全量内存加载，靠数据库索引+分批游标拉取实现O(n)时间复杂度的比对，全程内存无堆积：

• 前置准备：给两个待比对集合（简称collA、collB）的比对主键（_id或业务唯一键，比如orderId、userId）建升序索引，需要比对的业务字段如果有过滤需求也可以建联合索引，这步是性能基础，没索引全表扫性能会差10倍以上。建索引命令参考：

db.collA.createIndex({bizId:1})
db.collB.createIndex({bizId:1})

• 数据拉取：绝对不要用find().into()/find().toList()这类一次性拉全量的API，用Java驱动的原生游标，配置batchSize=1000，每次只从Mongo服务端拉1000条数据到本地，查询时直接按比对主键升序排序，因为有索引，排序是零开销的，拉出来的数据流天然有序。游标用try-with-resources包裹自动关闭，避免连接泄漏。Java侧游标写法参考：

try (MongoCursor<Document> cursorA = collA.find()
        // 只投影需要比对的字段，无关字段不要查，减少70%传输和内存开销
        .projection(Projections.include("bizId", "compareField1", "compareField2"))
        .sort(Sorts.ascending("bizId"))
        .batchSize(1000)
        .cursorType(CursorType.NonTailable)) {
    // 比对逻辑
}

• 比对逻辑：两个游标分别维护当前读取位置，用经典双指针法逐段比对，全程不需要把全量数据放内存：
  • 两个游标各取当前批次的第一条记录，比对主键值：
    • 主键相等：逐字段比对内容，存在差异就写入差异结果缓存，两个游标同时后移一位
    • collA的主键更小：说明这条记录只在collA存在，写入独有的差异缓存，collA游标后移一位
    • collB的主键更小：说明这条记录只在collB存在，写入独有的差异缓存，collB游标后移一位
  • 任意游标当前批次的1000条读完，自动触发下一批次拉取，直到两个游标全部遍历完成
• 内存控制：内存里永远只存两个当前批次共2000条待比对记录，差异缓存攒够500条就批量插入专门的差异结果集合，插入完成立刻清空缓存，全程堆内存占用稳定在50MB以内，不会触发Full GC。
• 性能参考：3节点副本集环境，单条文档平均800B，200w+200w量级数据单线程跑完全程耗时7~8分钟，不需要开多线程。

方案2：分片并行比对（适合单线程性能不满足需求的场景，内存依然可控） #

如果你的部署环境CPU、Mongo连接数充足，可以在流式比对的基础上做分片并行，进一步压缩耗时，注意不要开超过CPU核心数的线程，避免上下文切换开销：

• 拆分规则：按比对主键做哈希取模，比如拆成8/16个分片，每个分片负责查询hash(bizId) % 分片数 = N的子集，两个集合用完全一致的拆分规则，避免漏数。
• 并行逻辑：线程池核心线程数和CPU核心数持平，每个线程独立维护两个分片的游标，独立跑双指针比对逻辑，差异结果统一攒批写入差异集合。
• 内存控制：每个线程的内存占用和单线程方案一致，8线程场景总堆内存占用也不会超过500MB，完全可控，性能比单线程提升3~5倍。

必看避坑点 #

• 不要给比对逻辑加多余的锁：双指针/分片比对的逻辑本身是线程隔离的，不需要加同步锁，加锁反而会把并行退化成串行。
• 不要查全字段：查询时一定要用投影只取需要比对的字段，大字段、不需要比对的字段全部过滤掉，能大幅减少网络IO和内存占用。
• 不要把差异结果存在本地内存/本地文件：差异数据量不可控，攒批写库是最稳妥的方式，避免差异量太大撑爆内存。

生产实测踩坑记录：之前试过开32线程做全量内存比对，16G堆都跑OOM，换成单线程流式双指针方案，512MB堆就跑完全程，耗时只有之前多线程方案的1/4。

内容的提问来源于stack exchange，提问作者Hicham Moro