MongoDB的sort()必须使用索引最左前缀，否则触发内存排序；索引需按filter字段+sort字段顺序创建，方向须严格一致，limit不改变索引匹配逻辑，验证需关注executionStats中IXSCAN、totalDocsExamined与nReturned是否相等及indexName是否正确。
sort字段必须在索引最左前缀中
MongoDB 的 sort() 操作无法利用跳过前导字段的索引。如果查询带 sort({ price: 1, name: -1 })，但索引是 { category: 1, price: 1, name: -1 }，那么排序阶段仍会触发内存排序（EXECUTOR_ERROR 或日志里出现 Sort exceeded memory limit），因为 category 是非查询条件的前导字段，引擎无法跳过它来按 price 直接扫描。
实操建议：
- 先确认查询中实际用到的
filter字段（如{ status: "active", category: "book" }），再把sort字段紧接其后定义索引 - 若无 filter，只有
sort + limit（例如分页首页），索引应直接以 sort 字段开头，如db.items.createIndex({ created_at: -1 }) - 复合索引中，sort 方向（
1或-1）必须与查询中完全一致；混合方向索引（如{ a: 1, b: -1 }）不能支持sort({ a: 1, b: 1 })
limit 不降低索引设计复杂度，只影响执行路径
limit(10) 不会让 MongoDB “少建字段”——它不改变索引匹配逻辑，只限制最终返回文档数。真正决定是否走索引扫描+排序还是内存排序的，是索引能否覆盖 filter + sort 的完整顺序。
常见错误现象：
- 加了
limit(1)就以为不用管 sort 字段顺序，结果explain("executionStats")显示stage: "SORT"，说明仍在内存排序 - 误以为
limit能让稀疏索引“自动跳过 null”，其实稀疏性只影响索引条目是否写入，不影响 sort 路径选择 - 在聚合管道里用
$sort + $limit，却忘了$sort阶段同样依赖前置索引；此时需确保$sort字段在$match后仍有对应索引前缀
避免在高基数字段上盲目加 sort 索引
像 updated_at 这类高频更新字段，如果建了 { updated_at: -1, _id: 1 } 用于分页，每次文档更新都会触发索引项重排，写放大明显，尤其在副本集同步压力下可能拖慢主节点。
使用场景权衡：
- 读远多于写（如日志归档表），且分页稳定（如按时间倒序查最新 20 条），适合建
{ updated_at: -1, _id: 1 } - 写密集型集合（如用户实时行为流），优先考虑游标分页（用上一页最后的
updated_at + _id做下一页$gt查询），而非skip/limit，这样可复用同一索引避免排序 - 若业务允许，把 sort 字段降级为低频更新值（如预计算的
score_rank），并配合 TTL 索引控制体积
验证索引是否生效的三个关键字段
别只看 explain().queryPlanner.winningPlan 里有没有 IXSCAN。真正要盯的是执行阶段细节：
-
executionStats.totalDocsExamined === executionStats.nReturned：理想情况，说明没扫多余文档（即索引覆盖了 filter + sort 范围） -
executionStats.executionStages.stage === "IXSCAN"且没有子节点含"SORT"：确认排序由索引完成，未进内存 -
executionStats.executionStages.indexName必须是你预期的那个；有时多个相似索引并存，MongoDB 可能选错（比如选了{ a: 1 }而不是{ a: 1, b: -1 }），这时要用hint()强制验证
容易被忽略的是：当集合有大量重复 sort 值（如 status: "pending" 占 80%），即使索引存在，MongoDB 也可能因 selectivity 估算偏差放弃 IXSCAN，改走 COLLSCAN + SORT——这时得加低基数字段（如 status）进索引前缀来提升区分度。
