必须将等值查询字段置于复合索引最左，再接排序字段并严格匹配方向，否则无法避免内存排序；仅建纯排序索引如{field1: 1, field2: -1}大概率无效。
直接给结论：只建 {field1: 1, field2: -1} 这类纯排序索引，大概率白干；必须把查询条件字段塞进索引最前面，再接排序字段，才能真正避免内存排序（SORT 阶段）。
为什么 sort({a: 1, b: -1}) 不一定走你建的 {a: 1, b: -1} 索引
MongoDB 查询优化器不是“看到字段匹配就用”，而是严格按索引字段顺序匹配查询谓词。如果查询带了 find({status: "active"})，但你只建了 {createdAt: -1, priority: 1}，那这个索引根本不会被选中——它压根不包含 status，无法用于过滤。
常见错误现象：
- 执行
explain("executionStats")后看到"stage": "SORT"，说明在内存里硬排，不是走索引 -
"nReturned"很小但"executionTimeMillis"很高，典型内存排序拖慢 - 索引存在，但
indexBounds显示为空，代表没用上
createIndex() 字段顺序必须遵循 ESR 规则
ESR 是硬性顺序：Equal → Sort → Range。不是建议，是查询优化器实际匹配逻辑。
使用场景举例：你要查 find({status: "active", createdAt: {$gt: ISODate("2025-01-01")}}).sort({priority: 1})
正确索引写法：
db.items.createIndex({"status": 1, "createdAt": 1, "priority": 1})
不能写成：
-
{"priority": 1, "status": 1}—— 排序字段放最前，等值字段被跳过 -
{"createdAt": 1, "status": 1, "priority": 1}——status不是首字段，无法高效等值过滤 -
{"status": 1, "priority": 1, "createdAt": 1}—— 范围字段createdAt放在排序字段priority后面，会导致范围扫描失效
排序字段方向必须和 sort() 完全一致
MongoDB 不会反转索引方向来适配查询。升序索引 {a: 1, b: 1} 无法服务 sort({a: 1, b: -1})。
参数差异关键点：
- 复合索引中每个字段的方向（
1或-1）必须与sort()中对应字段方向一致 - 但等值字段方向无所谓：
{"status": 1}和{"status": -1}效果一样，因为等值不依赖顺序 - 如果排序含多个字段，且方向混用，索引也得严格对应，比如
sort({a: -1, b: 1, c: -1})需要索引{a: -1, b: 1, c: -1}
性能影响：方向不一致时，优化器宁可走全表扫描 + 内存排序，也不用索引。
重复值多的排序字段必须加 _id 保一致性
当 sort() 字段存在大量重复值（比如按 status 排序），MongoDB 不保证相同 status 的文档返回顺序稳定——底层 BSON 比较可能受插入顺序、内存分配等影响。
解决办法很简单：在 sort() 最后补一个唯一字段，通常是 _id：
db.users.find().sort({status: 1, _id: 1})
这样即使 status 值相同，也会按 _id 二次排序，结果可重现。注意：这个 _id 不需要额外建进索引，因为 _id 本身是主键索引，且 MongoDB 会在索引末尾自动隐含 _id 值用于去重和排序稳定性。
容易被忽略的地方：很多人以为只要索引覆盖了 sort() 字段就万事大吉，但忘了排序稳定性不是性能问题，而是业务逻辑问题——分页跳变、前端列表闪动，往往就出在这里。
