ESR索引设计必须严格遵循等值（E）→排序（S）→范围（R）顺序：E字段最左以定位数据块，S字段次之利用B-Tree有序性直接输出，R字段最右因范围扫描会中断后续字段有效性；同一字段不可兼属S与R组；创建后需用.explain()验证IXSCAN阶段及索引名。
当你的MongoDB查询包含等值条件、排序需求和时间范围筛选时，索引设计不当会导致内存排序、全索引扫描甚至OOM风险，必须严格按ESR顺序组织字段。
理解ESR三要素的物理约束
ESR不是经验法则，而是B-Tree索引结构决定的硬性限制：等值字段（E）必须放在最左，它让索引能快速跳转到数据块；排序字段（S）紧随其后，利用B-Tree天然有序性直接输出结果；范围字段（R）只能放最右，一旦出现范围扫描，索引后续字段的有序性立即中断，无法再支撑排序。
例如查询 { userId: "U1001", status: "paid", amount: { $gt: 100 } } → 若索引为 { userId: 1, amount: 1, status: 1 }，则 amount 的范围扫描会切断 status 字段的索引有效性，导致status过滤退化为内存逐条比对。
【范围字段之后的所有字段在查询中完全失效】
按查询模式反推索引字段顺序
先列出你实际执行的查询语句，提取出三个部分：
① 所有 $eq、== 或字面量精确匹配的字段 → 全部归入E组；
② .sort() 中的字段及方向（如 { createdAt: -1 }）→ 归入S组；
③ 所有 $gt、$gte、$lt、$in（非单值）、$regex（非前缀）等 → 归入R组。
注意：同一个字段不能既在S组又在R组；若某字段在查询中既用于等值又用于范围（如 { tag: "vip", score: { $gte: 90 } }），它必须拆成两个独立索引字段处理，不能复用。
创建复合索引的具体命令
方法一：使用mongosh执行createIndex
db.orders.createIndex({ userId: 1, status: 1, amount: -1, createdAt: 1 })
这条命令对应查询：db.orders.find({ userId: "U1001", status: "paid" }).sort({ amount: -1 }).limit(20)，其中createdAt未出现在查询中，但预留为未来范围扩展位——只要不把它插在amount前面，就不破坏ESR。
方法二：在MongoDB Atlas控制台操作
进入「Collections」→ 选择目标集合 → 点击「Indexes」→ 「Create Index」→ 在字段输入框依次填入 userId（1）、status（1）、amount（-1）、createdAt（1）→ 点击「Create Index」。
方法三：用驱动程序（Node.js示例）
await db.collection("orders").createIndex({ userId: 1, status: 1, amount: -1, createdAt: 1 });
这一步执行后，索引即刻生效，无需重启服务或刷新缓存。
验证索引是否真正生效
运行带 .explain("executionStats") 的原始查询：
db.orders.find({ userId: "U1001", status: "paid" }).sort({ amount: -1 }).explain("executionStats")
重点检查返回结果中的 executionStats.executionStages.stage 是否为 IXSCAN，且 executionStats.executionStages.indexName 显示为你刚创建的索引名；若出现 COLLSCAN 或 SORT 阶段，则说明索引未命中或被忽略。
如果 nReturned 远小于 totalDocsExamined，说明索引前缀匹配失败，需回查E字段是否全部出现在查询条件中。
