MongoDB大结果集下set/intersection使用异常问题咨询

看起来你遇到的问题是在数据量增大后，基于set/intersection的交集筛选开始丢失符合条件的记录。我来帮你拆解可能的原因和对应的解决方案：

首先排查基础查询的正确性 #

你的核心逻辑是对每个关键词前缀调用photos-with-keyword-starting（单数）获取照片，再转成集合求交集。如果交集结果不对，首先要确认单个关键词前缀的查询是否能返回所有匹配的照片：

• 手动在MongoDB Shell中执行和photos-with-keyword-starting相同的查询，对比返回的文档数量和函数返回的数量。如果数量不一致，说明基础函数的查询有问题：
  • 检查是否不小心加了limit或者分页逻辑，导致大数量时只返回了部分结果；
  • 确认$regex的写法是否正确：比如是不是用了^前缀来匹配关键词开头？有没有考虑大小写敏感的问题（比如需要加$options: "i"）？
  • 查看MongoDB的查询计划，确认是否因为索引问题导致查询没有命中所有匹配的文档（比如用了前缀索引但查询条件不匹配索引规则）。

检查集合元素的一致性问题 #

如果单个查询的结果是完整的，那大概率是set的元素比较逻辑出了问题：

• 你当前是把整个照片文档放进set里，但MongoDB文档在序列化/反序列化时，可能出现字段顺序变化、某些可选字段缺失的情况，这会导致同一个照片的两个实例被set视为不同元素，从而在交集中被排除。
• 解决方案是用照片的唯一标识（比如_id）来做交集，而不是整个文档。修改后的代码可以这样写：

(defn photos-with-keywords-starting [stems]
  (let [; 先获取每个关键词对应的照片ID集合
        id-collections (map (fn [stem]
                              (set (map :_id (photos-with-keyword-starting stem))))
                            stems)
        ; 计算ID的交集
        common-ids (apply set/intersection id-collections)]
    ; 根据交集的ID批量查询完整照片
    (monger.collection/find-maps "photos" {:_id {:$in (vec common-ids)}})))

这样只比较唯一的_id，就能避免文档序列化带来的不一致问题。

优化：把交集逻辑移到数据库层面 #

用内存做set/intersection在数据量大时不仅效率低，还容易出现各种内存层面的问题。更优的方式是让MongoDB直接返回同时满足所有关键词前缀的照片，比如通过$all结合正则表达式：

(defn photos-with-keywords-starting [stems]
  (monger.collection/find-maps "photos"
    {:keywords {:$all (map #(re-pattern (str "^" %)) stems)}}))

这个查询会直接从数据库中取出所有keywords数组里包含每个指定前缀关键词的照片，不需要在内存中做交集运算，既高效又能保证结果的准确性。

最后验证步骤 #

1. 先验证单个关键词的查询结果是否完整；
2. 如果用原逻辑，切换到用_id做交集；
3. 优先考虑用数据库层面的查询代替内存交集，从根源避免问题。

内容的提问来源于stack exchange，提问作者Eric Clack