MongoDB未选最优复合索引，为何优先使用_id_索引？

问题背景 #

我执行了如下MongoDB查询：

db.MDocumentContent.find({
            "updatedTime": {
                "$lte": ISODate('2023-08-20T16:00:00.000Z')
            },
            "type": {
                "$nin": [
                    "default",
                    "customFigureSample"
                ]
            },
            "isClean": {
                "$in": [
                    null,
                    false
                ]
            },
            "_id": {
                "$gt": ObjectId("611a18d87c62f5002fb0809c")
            }
        }).sort({ _id: 1 }).limit(10);

通过explain()工具分析查询执行计划后，发现查询优化器选择了默认的_id_单键索引，而非我创建的复合索引_id_1_updatedTime_1_type_1_isClean_1。我认为该复合索引更适配当前查询需求，想请教出现这一现象的原因。

可能的原因分析 #

• 小结果集下，单键索引成本更低
  你的查询加了limit(10)，优化器会计算不同索引的执行成本。通过_id_索引按顺序扫描，很快就能找到10条满足_id > 611a18d87c62f5002fb0809c的文档，之后在内存中过滤updatedTime、type、isClean这几个条件的开销，比走复合索引的成本更低——复合索引的条目体积更大，加载和扫描的额外开销反而不划算。

• 复合索引的字段顺序限制了有效利用范围
  你的复合索引是_id_1_updatedTime_1_type_1_isClean_1，虽然_id是前缀，但后续字段的查询条件无法充分利用索引：

  • type使用$nin，属于非等值匹配，会中断复合索引的字段链，后面的isClean字段无法再通过索引过滤；
  • isClean的$in同样属于非精确匹配，即使没有前面的$nin，也只能有限利用索引。
    最终这个复合索引实际能发挥作用的只有_id前缀部分，和单键_id_索引效果相近，但复合索引的存储和扫描成本更高，优化器自然会选更轻量的单键索引。

• 统计信息过时导致优化器预估偏差
  MongoDB的查询优化器依赖集合的统计数据（文档数量、字段分布、索引基数等）来评估成本。如果统计信息长时间未更新，优化器可能错误判断复合索引的性能，导致选错索引。可以执行db.MDocumentContent.runCommand({ collStats: 1 })查看统计信息的更新时间，或者用db.MDocumentContent.reIndex()刷新索引统计数据。

• 内存缓存的影响
  如果_id_索引的数据已经完全加载到内存缓存中，而复合索引的大部分数据还在磁盘上，优化器会优先选择缓存中的索引——磁盘IO的成本远高于内存扫描，即使复合索引理论上更优，实际执行时缓存带来的性能提升会让优化器倾向于选择单键索引。

内容的提问来源于stack exchange，提问作者GO-DIE