MeteorJS中MongoDB带子查询的$lookup聚合性能异常缓慢问题排查

普通$lookup（无pipeline）的高效逻辑 #

当你使用不带pipeline的$lookup，结构类似：

{
  $lookup: {
    from: "sales",
    localField: "_id",
    foreignField: "customerIds",
    as: "relatedSales"
  }
}

MongoDB会采用**哈希连接（Hash Join）**的批量处理方式：

• 第一步：从customers集合读取所有目标文档，提取出所有_id值组成一个集合。
• 第二步：一次性对sales集合执行查询，利用customerIds上的索引，快速定位所有customerIds包含任意上述_id的文档。
• 第三步：将查询到的sales文档与对应customers文档做关联匹配。

整个过程只需要对sales集合做一次索引查询/扫描，批量处理所有关联逻辑，所以耗时仅1.5秒，完全符合预期。

带pipeline的$lookup的低效根源 #

当你使用带let和pipeline的$lookup，比如：

{
  $lookup: {
    from: "sales",
    let: { custId: "$_id" },
    pipeline: [
      { $match: { $expr: { $in: ["$$custId", "$customerIds"] } } }
    ],
    as: "relatedSales"
  }
}

在MongoDB 4.4版本中，默认采用嵌套循环连接（Nested Loop Join）：

• 对customers集合中的每一条文档，单独执行一次pipeline内的$match查询——也就是针对当前客户的_id，去sales集合查找包含该ID的文档。
• 你的customers有6万条文档，意味着要发起6万次独立的sales查询。哪怕每次查询只消耗0.3毫秒，累加起来就是18秒，再加上查询调度、内存开销等，总耗时超过20秒完全合理。

这种方式不是因为网络往返次数增加（同一实例内是内部调用），而是逐个处理父文档导致的重复查询开销——多次小查询的总开销远大于一次批量查询的开销。

验证方式 #

你可以给两种聚合查询添加explain("executionStats")，对比执行计划：

• 普通$lookup会看到HASH_JOIN的执行阶段，sales集合的扫描次数仅为1次。
• 带pipeline的$lookup会看到NESTED_LOOP阶段，并且子查询的执行次数等于customers的文档数量（约6万次）。

优化建议 #

1. 如果业务逻辑不需要在lookup阶段做额外复杂处理，优先使用普通$lookup，保持高效的批量处理。
2. 如果必须使用pipeline（比如需要过滤特定状态的销售记录、投影字段等），可以调整逻辑：
   • 先从customers提取所有_id，然后在sales集合中用$match: { customerIds: { $in: [所有custId] } }批量过滤，再通过$lookup关联（或者调换关联顺序）。
   • 升级到MongoDB 5.0及以上版本，该版本对带pipeline的$lookup增加了哈希连接优化，能自动将部分场景的嵌套循环转换为批量处理。

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