使用$or时MongoDB查询性能骤降，为何无法复用复合索引？

1. 你的多$or写法存在语法逻辑错误 #

在JSON/BSON对象中，重复的键会被最后一个值覆盖，你当前的$match里连续定义了多个$or键，最终只有最后一个针对字段I的$or条件会生效，其余字段的$or条件全部被丢弃。实际执行的查询等价于：

{
  $or: [{ I: { $eq: 1 } }, { I: { $eq: 2 } }],
  B: { $eq: 500 }
}

这种情况下，你的复合索引前缀是A,C,D,E,F,G,H,I,B，仅靠I和B的条件无法匹配复合索引的前缀匹配规则，因此查询会走集合扫描。

2. 即使修正写法，多$or组合也难以利用单个复合索引 #

假设你修正写法，用$and包裹所有$or条件（实现你预期的“同时满足每个字段二选一+B=500”的逻辑），比如：

{
  $and: [
    { $or: [{ A: 1 }, { A: 2 }] },
    { $or: [{ C: 1 }, { C: 2 }] },
    { $or: [{ D: 1 }, { D: 2 }] },
    // ... 其余字段的$or条件
    { B: 500 }
  ]
}

此时MongoDB依然难以复用你的复合索引，核心原因是：

• 复合索引是按字段顺序有序存储的，它的最优使用场景是“前缀字段等值匹配→后续字段等值/范围匹配”的连续条件链。
• 每个$or是对单个字段的多值判断，多个$or的组合相当于对多个非连续字段分别做范围筛选，MongoDB无法通过复合索引的有序结构一次性定位所有符合条件的文档。
• 而你之前用$in的写法，本质是对每个字段的等值多值查询，完全贴合复合索引的存储逻辑：索引会先按A的排序快速筛选出A=1/2的条目，再在这个子集里按C筛选，以此类推，最后匹配B=500，因此能高效走索引扫描。

3. MongoDB对$or的索引使用规则限制 #

MongoDB对$or的索引支持有明确约束：

• $or的每个子条件都需要能单独匹配一个索引（可以是同一个复合索引的不同前缀，也可以是不同的单字段/复合索引）。
• 对于多$or+$and的组合，MongoDB需要为每个$or子条件执行独立的索引扫描，再合并、去重结果，这个过程的开销远大于单索引扫描，甚至在数据量较大时，优化器会直接选择集合扫描来避免多次索引扫描的额外开销。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture