MongoDB 4.4.2中两种$lookup聚合管道40倍性能差异原因咨询

没错，你猜的完全准确——第二种$lookup的写法确实没有用到players集合id字段上的唯一索引，这就是两者性能差出40倍的核心原因。

为什么两种写法性能天差地别？ #

第一种是$lookup的传统等值关联模式（localField+foreignField），MongoDB能直接识别这是简单的字段等值匹配，会自动调用players.id上的唯一索引做高效的索引查找，相当于内部做了批量的索引查询，所以5000条数据仅需3秒就能完成关联。

而第二种用了带自定义子管道的$lookup，你在子管道的$match里通过$expr引用了外部变量$$pid来做等值判断。在MongoDB 4.4版本中有个关键限制：当$expr引用来自父集合的外部变量时，MongoDB无法直接利用目标集合的常规字段索引。这就导致每次关联都要对players集合做全表扫描，5000条父文档就会触发5000次全表扫描（每次扫2600条数据），总操作量飙升到1300万次，耗时自然就涨到了120秒。

如何验证是否真的没用到索引？ #

你可以给第二种查询加上执行计划分析，运行下面的命令：

db.your_collection.aggregate([
  {'$match': {}},
  { '$lookup': {
      'from': 'players',
      'let': { 'pid': '$player_id' },
      'pipeline': [
        { '$match': { '$expr': { '$and': [ { '$eq': ['$id', '$$pid']}, ]}} }
      ],
      'as': 'result',
    }
  }
]).explain("executionStats")

查看输出中players子管道的执行统计，如果看到stage字段值为COLLSCAN（全表扫描），就坐实了没有用到索引。

怎么解决这个性能问题？ #

1. 优先用传统等值模式：如果你的关联逻辑只是简单的player_id和id等值匹配，直接用第一种localField+foreignField的写法就足够了，它就是为这种场景做了专门优化，性能拉满。
2. 升级MongoDB版本：如果确实需要用自定义子管道实现更复杂的关联逻辑（比如还要叠加其他过滤条件），MongoDB 5.0及以上版本针对$expr引用外部变量的场景做了索引优化，升级后这种写法就能正常使用players.id的索引了。

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