MongoDB索引选择异常咨询：为何非预期索引被优先选用？

查询语句 #

db.my_collection.find({ 
  "$and": [ 
    { "expires_at": { "$ne": ISODate("0001-01-01T00:00:00Z") } }, 
    { "expires_at": { "$lte": ISODate("2024-03-29T16:00:00Z") } }, 
    { "operation.updated_at": { "$lte": ISODate("2024-03-29T16:00:00Z") } }
  ], 
  "operation.status": 3, 
  "is_in_some_state": true, 
  "system_type": "type3", 
  "some_status": 1 
})

已创建索引 #

operation.status_1_expires_at_1
// some other indexes for other requests
expires_at_1_operation.updated_at_1_operation.status_1_is_in_some_state_1_system_type_1_some_status_1

性能对比 #

• operation.status_1_expires_at_1：查询耗时1秒以上
• 全字段复合索引：查询耗时约700毫秒
• system_type_1：查询耗时仅70毫秒

数据分布统计 #

db.my_collection.aggregate([{$group:{_id:"$system_type",count:{$sum:1}}},{$sort:{count:-1}}])
// 统计结果：
{ "_id" : "type1", "count" : 637289 }
{ "_id" : "type2", "count" : 295798 }
{ "_id" : "type3", "count" : 80788 }
{ "_id" : "type4", "count" : 5 }

核心疑问与解答 #

1. 为何MongoDB选择operation.status_1_expires_at_1而非全字段复合索引？ #

MongoDB查询优化器基于索引基数、过滤后文档量、索引体积等维度计算执行代价，选择它认为成本最低的方案：

• 全字段复合索引以expires_at开头，但查询中expires_at同时使用了$ne和$lte，$ne属于范围类查询，会直接导致复合索引后续字段的过滤能力失效。优化器判断，先通过operation.status=3（等值匹配）快速缩小数据集，再过滤expires_at的成本，低于从expires_at范围查询切入的成本。
• 若全字段索引较新或数据分布发生过变化，MongoDB的统计信息可能未及时更新，导致优化器误判索引的实际过滤效率——这也是手动用hint指定全字段索引后性能提升的原因。

2. 为何单一system_type_1索引性能优于全字段复合索引？ #

从数据分布看，system_type="type3"仅占总数据的约7.3%，属于高选择性等值条件：

• 单一字段索引的体积远小于全字段复合索引，MongoDB加载和扫描该索引的IO成本极低。
• 过滤出8万条type3数据后，剩余文档量很小，即使在内存中完成后续条件过滤（operation.status=3、expires_at范围等），总耗时也远低于扫描大体积复合索引的成本。
• 全字段复合索引虽覆盖了所有查询字段，但开头的expires_at是范围查询，导致后续字段无法被高效利用，实际过滤效率不如直接从高选择性的system_type切入。

3. 查询system_type="type1"时为何仍使用system_type_1索引？ #

即使type1占比63%，优化器依然选择该索引的核心原因是总成本最低：

• system_type_1是单一字段索引，体积最小，扫描速度最快，IO成本远低于其他索引。
• 过滤出63万条type1数据后，MongoDB可在内存中快速完成剩余条件的过滤，这个内存操作的成本，依然低于扫描operation.status_1_expires_at_1或全字段复合索引的IO成本。
• 优化器评估的是“索引扫描+后续过滤”的总成本，而非仅看过滤后的文档数量，对于type1场景，单一索引的总代价仍低于其他选项。

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