MongoDB带$exists条件的窄查询比泛查询更慢的原因及解决方法

1. 查询优化器未正确识别稀疏复合索引的特性
   你创建的{strField: 1, dateTimeField: 1}稀疏复合索引，仅会收录同时存在strField和dateTimeField两个字段的文档，理论上完全匹配strField: 'AAA' + dateTimeField: {$exists: true}的查询条件。但MongoDB查询优化器无法主动推导「该索引中的所有条目天然满足dateTimeField: {$exists: true}」的逻辑，因此执行查询时会先定位到strField: 'AAA'的所有匹配条目，再逐篇回表校验dateTimeField是否真实存在，当strField: 'AAA'的文档量级很大时，大量随机IO就会导致查询耗时极长。
2. 强制hint无效的核心逻辑
   即便指定hint强制走该稀疏索引，MongoDB仍会执行回表校验逻辑，并不会直接使用索引条目做count统计，因此无法解决回表带来的性能损耗。
3. 额外排查点
   如果集合中存在大量dateTimeField值为null的文档，$exists: true会匹配这类「字段存在但值为空」的文档，稀疏索引会正常收录这类文档，如果你实际需要统计的是dateTimeField有有效值的条目，查询条件的偏差也会导致扫描范围变大。

• 方案1：省略多余的$exists校验
  你使用的稀疏复合索引已经天然过滤了所有dateTimeField不存在的文档，直接执行以下查询即可，优化器可以直接统计索引条目数，不需要回表，返回结果和原查询完全一致：

db.mycollection.find({ strField: 'AAA' }).hint("你的稀疏索引名称").count()

• 方案2：改用部分索引替代稀疏索引
  如果后续还有其他针对dateTimeField的查询场景，可以创建部分索引明确指定过滤规则，查询优化器可以直接识别索引的过滤条件，不需要回表校验：

db.mycollection.createIndex(
  { strField: 1, dateTimeField: 1 },
  { partialFilterExpression: { dateTimeField: { $exists: true } } }
)

创建完成后直接执行原查询即可自动命中该索引，不需要额外指定hint。

• 方案3：如果需要同时兼容dateTimeField不存在的查询场景，可以为strField和dateTimeField分别创建单列普通索引，查询时优化器会自动选择索引交集完成count，性能也远高于全表回扫。

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