Mongoose聚合嵌入字段后搜索分页的性能及方案评估

方案一：先查User获取userId再用$in查询Request #

这种方案的性能核心取决于两个关键因素：username的唯一性，以及查询返回的userId数量。

• 如果username是业务上的唯一字段（通常场景都是如此），查询User集合只会得到单个userId，此时$in等价于普通的等值匹配。只要Request集合的userId字段建有索引，查询性能和常规单条件查询完全一致，没有任何性能问题。
• 如果允许重复username，返回多个userId：MongoDB官方明确提到，当$in的数组包含**大量值（数百以上）**时，查询性能会明显下降——因为数据库需要遍历数组中的每个值，逐一执行索引匹配。如果userId数量在数十到数百之间，性能尚可接受；但如果超过上千，索引匹配的累计开销会显著增加，导致查询变慢。

方案二：聚合管道关联User后查询分页 #

这个方案的性能差异极大，完全取决于聚合管道的执行顺序：

• 优化后的管道顺序：先通过$match筛选出匹配目标userId的Request文档（相当于先完成方案一的第二步），再用$lookup关联User集合获取username，最后执行分页。这种情况下，管道的性能和方案一几乎一致——大部分数据在$match阶段就被过滤掉，后续的关联和分页操作只处理少量数据，和SQL中WHERE先于JOIN的高效写法逻辑完全对齐。
• 未优化的管道顺序：先对所有Request文档执行$lookup关联User，再用$match过滤username，最后分页。这种写法相当于全表关联后再过滤，一旦Request集合数据量较大，性能会非常差，远不如方案一。

性能优劣总结 #

1. 若username唯一：方案一最优，两次简单索引查询，性能最高，代码实现也最简洁。
2. 若username可能重复且返回userId数量较少（数百以内）：方案一和优化后的方案二性能接近，可根据业务代码的复杂度选择。
3. 若username重复且返回userId数量极大（上千以上）：优化后的方案二略优于方案一（聚合管道可以在数据库端完成所有操作，减少客户端与数据库的交互次数），但核心前提是必须先做$match过滤再执行关联。

关于$in性能的官方说明 #

MongoDB官方文档明确指出：当$in操作符的数组包含大量元素时，查询性能会随着数组大小的增加而降低。这是因为数据库需要为数组中的每个元素执行独立的索引查找操作，元素越多，整体开销越大。官方建议将$in的数组元素数量控制在合理范围内（通常数百以内），超出范围时考虑拆分查询或使用聚合管道替代。

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