MongoDB如何借助索引处理多条件逻辑查询？
复合索引字段顺序必须严格遵循ESR规则：等值查询字段放最前，排序字段居中，范围查询字段放最后；$in属于范围操作，不能享受等值穿透能力；需用explain("executionStats")验证keysExamined、docsExamined与nReturned是否匹配；覆盖查询要求索引包含全部查询条件和投影字段。
复合索引字段顺序必须严格遵循 ESR 规则
多条件查询不是简单把所有 filter 字段塞进一个索引就完事。MongoDB 只能高效使用复合索引的「前缀连续段」，且字段顺序直接影响能否命中、扫描多少数据。ESR（Equality → Sort → Range）是硬性逻辑：等值查询字段放最前，排序字段居中，范围查询（$gt、$in、$regex 等）必须放最后。
比如这个慢查询：
db.items.find({ alxxxId: "ABC123", state: 0, itemTagList: { $in: ["tag1", "tag2"] }, persxxal: 0})
它用了 {alxxxId: 1, itemTagList: 1} 索引，但 itemTagList 是 $in（属于范围操作），而 state 和 persxxal 这两个等值条件被跳过了——索引根本没用上它们的筛选能力，导致 keysExamined 和 docsExamined 高达 1498，只返回 3 条。
- 正确顺序应为：
{alxxxId: 1, state: 1, persxxal: 1, itemTagList: 1}（三个等值 + 一个范围） - 如果还有
.sort({createdAt: -1})，就得把createdAt插在等值之后、范围之前：{alxxxId: 1, state: 1, persxxal: 1, createdAt: -1, itemTagList: 1} - 一旦范围字段出现在中间（比如
{alxxxId: 1, itemTagList: 1, state: 1}），后面所有字段都失效
避免用 $in 破坏索引前缀连续性
$in 在 MongoDB 中被归类为范围操作，不是等值。哪怕你写的是 {status: {$in: ["active"]}}，它依然无法享受等值字段的索引穿透能力。这是很多人踩坑的隐形点。
常见错误场景：
- 误以为
{type: "user", tags: {$in: ["vip"]}}能用{type: 1, tags: 1}索引高效过滤——实际只能用上type前缀，tags部分退化为内存过滤 - 用
$in查数组字段时，若数组元素多，索引条目会指数级膨胀，反而拖慢写入和内存占用 - 替代方案：如果业务上
$in的值集固定且较小（如状态枚举），可拆成多个$or+ 单值查询，或改用部分索引（partialFilterExpression）预筛
用 explain("executionStats") 验证是否真走索引
别信“planSummary 显示 IXSCAN 就万事大吉”。关键要看 executionStats 里的三个数字：
-
keysExamined：索引里实际比对的键数量 -
docsExamined：从磁盘/内存加载并检查的文档数（理想情况应 ≈nReturned） -
nReturned：最终返回的文档数
如果 keysExamined 是 2000，nReturned 是 5，说明索引筛选效率极低——大概率是字段顺序错、或用了不支持索引的运算符（如 $ne、$not、未加锚点的 $regex）。
执行示例：
db.items.find({ alxxxId: "ABC123", state: 0, persxxal: 0, itemTagList: { $in: ["tag1"] }}).explain("executionStats")
覆盖查询能彻底绕过文档读取
当 find() 的查询条件 + 投影字段（{field: 1}）全部被同一个索引包含，MongoDB 就不需要加载原始文档，直接从索引返回结果。这对高并发只读场景（如列表页）性能提升明显。
要达成覆盖查询，必须满足：
- 索引包含所有
filter字段（按 ESR 排序） - 索引还包含投影中所有字段（包括
_id，除非显式排除_id: 0） - 不能有
$text、$where、聚合阶段等破坏覆盖能力的操作
例如：
db.items.find( {alxxxId: "ABC123", state: 0}, {alxxxId: 1, state: 1, title: 1, _id: 0}).explain("executionStats")
对应索引应为：{alxxxId: 1, state: 1, title: 1}。此时 executionStats 中的 docsExamined 会是 0。
真正容易被忽略的是：即使索引字段全，只要投影里多了一个没建在索引里的字段（比如漏了 title），整个覆盖就失效，docsExamined 立刻回升。
