MongoDB中$nin查询为何比$in慢？5M文档场景下的性能疑问

这个场景我碰到过好多次了，核心原因在于MongoDB对这两个操作的索引利用逻辑和结果集规模差异，具体拆解一下：

• $in是精准定位小范围结果
  你的$in查询是找tech字段等于三个大小写变体的文档，MongoDB会直接利用tech上的索引，快速定位这三个值对应的索引条目，然后拉取对应的文档。本质上这是把三个单值查询合并执行，每个都走索引精准匹配，哪怕是500万条数据，只要这三个值的文档总数不多，整个过程的IO和计算量都很小，所以速度极快。

• $nin是反向筛选超大结果集
  而$nin的逻辑是排除这三个值，返回剩下的所有文档。这里的问题在于：

  1. 索引的设计初衷是帮你快速找到“符合条件的内容”，而不是快速排除“少数不符合的内容”。当你用$nin时，MongoDB即使走索引，也需要遍历索引中除了这三个值之外的几乎所有条目，然后逐一去拉取对应的文档——如果这三个值的文档占比极低（比如只占1%），那意味着要处理495万条文档，IO量直接拉满。
  2. 更糟的是，如果你的查询里只有$nin这一个条件，MongoDB甚至可能会选择全集合扫描而非索引扫描，因为遍历整个集合的开销可能比遍历大部分索引再去取文档的开销还小，这时候速度就更慢了。

额外优化建议（可选） #

如果你的场景经常需要做这类反向查询，有几个小技巧可以试试：

• 用不区分大小写的索引：通过collation设置strength: 2，这样tech字段的大小写会被统一处理，$in和$nin都只需要写一个值（比如'wordpress'），既简化查询，也避免索引里存重复的大小写变体。
• 调整查询逻辑：如果可能，尽量把反向查询转化为正向匹配（比如提前给非Wordpress的文档打个标签），利用$in的高效性。
• 限制结果集：如果不需要返回所有符合$nin的文档，记得加limit()，减少需要处理的数据量。

内容的提问来源于stack exchange，提问作者Максим Дихтярь