复合索引对多个$gte/$lte查询仅在满足最左前缀且字段连续时生效；跳过中间字段（如索引{a:1,b:1,c:1}中查{a:{$gte:1,$lte:5},c:{$gte:100,$lte:200}}）会导致c条件退化为内存过滤，必须补全b的等值或范围条件才能使c生效。
复合索引对多个 $gte/$lte 查询是否生效
不能直接覆盖多个独立的范围查询，除非它们作用于索引前缀连续字段，且查询条件满足“左前缀 + 单点/范围”组合。MongoDB 的 explain() 中若出现 indexBounds 显示多段区间（如 [ [10, 20], [30, 40] ]），说明它在尝试用单个索引键扫描多个不连续区间——这本身可行，但性能取决于区间数量和跨度。
真正失效的场景是：你在复合索引 {a: 1, b: 1, c: 1} 上执行 {a: {$gte: 1, $lte: 5}, c: {$gte: 100, $lte: 200}}。由于跳过了中间字段 b，MongoDB 无法构造有效边界，只能扫描整个 a 范围内的所有索引项，c 条件退化为内存过滤。
- 只有
a有范围 → 可用，边界形如[ [1,5] ] -
a和b都有范围 → 可用，边界形如[ [1,5], [10,20] ] -
a和c有范围、b缺失 → 不可用前缀，b字段被跳过，c边界被忽略 - 想让
c生效？必须显式提供b的等值条件（如b: 15）或范围（如b: {$gte: 10, $lte: 20}）
$elemMatch 是多键索引上做范围交集的唯一方式
当字段是数组、你又想对「同一个数组元素」同时满足多个范围条件时，$elemMatch 不是可选项，而是强制要求。没有它，MongoDB 就无法把多个谓词的索引边界相交，只能取各自边界的并集（更宽）或随机选一个（不可控）。
比如索引 {grades: 1}，查 “成绩在 90–99 之间的学生”，必须写成：
db.students.find({ grades: { $elemMatch: { $gte: 90, $lte: 99 } } })
否则写成 {grades: {$gte: 90, $lte: 99}}，MongoDB 实际执行的是：“数组里有 ≥90 的元素 且 有 ≤99 的元素”——这两个元素可以完全不同，甚至一个是 100、一个是 0，结果完全偏离预期。
-
$elemMatch触发边界交集：grades: [[90, 99]] - 无
$elemMatch→ 边界不交集，可能用[[90, Infinity]]或[[-Infinity, 99]]，全表扫风险高 - 嵌套文档数组也适用，例如
{scores: {subject: "math", score: 95}}，用$elemMatch才能绑定 subject 和 score
拆分查询前先确认是否真需要“覆盖”
所谓“覆盖多个 Range 查询”，常被误解为“一次查出所有满足任意范围组合的文档”。但 MongoDB 的索引机制决定了：它不支持对非前缀字段做高效范围扫描。与其强行堆砌复杂查询，不如判断业务本质。
例如查“价格在 100–200 或 500–600 的商品”，用 $or 是合理选择；但若写成 {price: {$gte: 100, $lte: 600}} 再靠应用层过滤，就浪费了索引能力。
- 用
$or时，每个分支可独立走索引（只要各自满足前缀规则） - 用
$in替代离散范围（如status: {$in: ["active", "pending"]}）比多个$gte/$lte更轻量 - 如果范围条件来自用户自由输入（如价格滑块），服务端应聚合为一个闭区间再查，而非拆成 N 个
$or分支 - 高频离散范围查询（如按分数段统计）可预计算存到新字段，用等值索引代替范围扫描
explain() 里最该盯住的三个字段
判断复合索引是否真正覆盖你的 Range 查询，别只看 executionStats.nReturned，重点看这三个：
-
executionStats.executionStages.indexBounds：显示实际使用的边界。如果是空或只有一维，说明后缀字段没参与扫描 -
executionStats.executionStages.totalKeysExamined：远大于nReturned？说明大量索引项被读出但被过滤掉，索引未覆盖 -
executionStats.executionStages.isMultiKey：为true时，多键索引的边界行为会变化（尤其涉及数组字段），需额外验证$elemMatch是否到位
特别注意：即使 indexOnly: true 出现在结果中，也不代表所有 Range 条件都被索引满足——它只表示返回字段全部来自索引，而查询条件仍可能部分回表过滤。
