MongoDB拆分$in查询为何性能大幅提升？

• $in列表大小带来的内存与索引遍历瓶颈
  当用2000个值的$in列表查询时，MongoDB需要把整个列表加载到内存，再在B树索引中逐个匹配。大列表会导致索引节点频繁在内存和磁盘间交换（若索引无法完全存入内存），缓存命中率暴跌。拆分后每次仅处理200个值，内存占用小，索引遍历的缓存命中率大幅提升，单轮索引扫描效率自然上去了。

• 小查询的并行执行优势
  MongoDB对小查询的调度更灵活。发起10次独立查询时，数据库能把这些任务分配到不同CPU核心并行执行，但单个大$in查询一般是单线程运行的。MongoDB 8.0虽有并行扫描优化，但对超大$in列表的支持有限，拆分后的小查询反而能充分利用多核资源，总耗时被并行执行摊薄。

• 聚合管道的阶段开销差异
  你用的是聚合管道里的$match阶段，大$in查询要处理整个列表的验证、与复合索引其他字段的逻辑整合，这些开销会随列表长度线性增长。拆分后的小查询，每个的聚合管道处理逻辑简单，单步开销极低，累加后的总开销反而远低于单次大查询。

• 复合索引的匹配效率变化
  你的复合索引包含learnerId和其他筛选字段，当$in列表过大时，数据库匹配复合索引时，每个learnerId都要匹配后续字段，会导致更多索引条目被扫描过滤。而小列表情况下，每个learnerId对应的索引条目更少，复合索引的匹配更精准，过滤效率更高。

• 查询优化器的执行计划选择
  MongoDB的优化器在处理超大$in列表时，偶尔会选错执行计划（比如放弃索引扫描走全表扫描，哪怕已建索引）。但拆分后的小查询，优化器会稳定选择索引扫描，避开了低效的执行路径。

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