mongodb聚合中$sort紧跟$match仍不走索引，因优化器仅在严格条件下下推排序：需复合索引覆盖$match前缀+范围字段+$sort字段且顺序一致，且中间无其他stage；$expr强制全表扫描；hint()在aggregate中无效；验证索引是否生效须看ixscan是否直接输出排序结果而非仅用于过滤。
聚合里 $sort 紧跟 $match 也不走索引？检查这三个硬条件
不是索引没建，而是 MongoDB 聚合优化器根本没把 $sort 下推到存储层——它只在极严格条件下才这么做。常见表现是 explain("executionStats") 里看到 "stage": "SORT"，且 "totalDocsExamined" 远大于 "nReturned"，甚至触发 Sort exceeded memory limit 错误。
必须同时满足以下三点，$sort 才可能跳过内存排序、直接用索引物理顺序返回：
-
$match条件字段 +$sort字段共同构成一个已存在的复合索引，且$match是前缀匹配（例如索引{status: 1, createdAt: -1}，查询{status: "done"}可以；但{createdAt: {$gt: ...}}就不行） - 索引字段顺序必须和 pipeline 顺序一致：先
$match等值字段，再范围字段，最后才是$sort字段 -
$sort必须紧跟在$match后面，中间不能插$project、$addFields、$lookup等任何 stage
聚合中调用 .hint() 报错或无效？它根本不支持
hint() 在聚合中不被支持——它只对 find() 有效。你写 db.orders.aggregate([]).hint({}) 会直接报错 undefined is not a function 或静默忽略。这是很多开发者踩坑的第一步。
想强制走某个索引，唯一可行路径是让聚合结构本身符合下推条件，或改用 find() + 游标操作替代部分逻辑。比如“查最新 10 条”这种需求，用：
db.orders.find({status: "shipped"}).sort({createdAt: -1}).limit(10).hint({status: 1, createdAt: -1})
显式加 hint() 是有效的，而聚合里不能这么干。
用了 $expr 就别指望索引——计算逻辑必须前置
$expr 查询几乎都不走索引，因其强制在文档层面运行时计算，无法下推至索引扫描阶段。即使字段有索引，含 $expr 的查询仍触发全表扫描。
常见错误写法：db.orders.find({$expr: {$lt: ["$createdAt", {$subtract: [new Date(), 7*24*60*60*1000]}]}}) —— explain() 一定显示 "stage": "COLLSCAN"。
正确做法是把计算挪到应用层：
- 在代码里先算出截止时间点：
const cutoff = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000) - 再传入普通查询：
db.orders.find({ createdAt: {$lt: cutoff } }) - 注意时区：Node.js 的
new Date()是本地时区，MongoDB 存的是 UTC，务必统一转换
验证索引是否真被聚合用了？别只看 IXSCAN 出没出现
别只看 explain("executionStats") 里有没有 IXSCAN，重点看它的位置和上下文：
- 如果
IXSCAN出现在最外层executionStages的inputStage里，且后面紧跟着"stage": "SORT"，说明索引只用于过滤，排序仍走内存 - 真正生效的表现是：
"stage": "IXSCAN"直接输出已排序结果，整个 pipeline 里找不到SORTstage，或者sortStage的"works"为 0 -
allowDiskUse: true反而可能干扰优化器判断，建议先去掉再测
一个快速验证命令：db.orders.explain("executionStats").aggregate([{$match: {status: "shipped"}}, {$sort: {createdAt: -1}}, {$limit: 10}])
聚合索引生效的边界非常窄，稍有偏差就退化为 COLLSCAN。最容易被忽略的是：pipeline 中看似无关的 stage（比如一个空 $addFields: {}）也会打断下推链路，导致整个排序逻辑掉回内存。
