$sort未走索引主因是未满足聚合索引下推的三个硬条件：必须存在匹配的复合索引，且$match为前缀匹配、索引字段顺序与pipeline一致、$sort紧接$match后；否则仍触发内存排序。
聚合中 $match 之后的 $sort 为什么没走索引？
不是索引没建，而是 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
db.collection.aggregate().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}) 是有效的，而聚合里不能这么干。
如何验证索引是否真被聚合用了？
别只看 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}])
聚合管道顺序调换后依然慢，还有什么漏掉？
即使把 $sort 放到 $match 后、删掉中间 stage、建了复合索引，还是慢？大概率卡在这几个隐形点：
- 索引方向和
$sort不一致：比如索引是{status: 1, createdAt: 1}，但你$sort: {createdAt: -1}，MongoDB 不会反向遍历索引，必须重建为{status: 1, createdAt: -1} - 查询条件含数组字段或嵌套对象：如
{tags: "urgent"}，即使tags有索引，若实际存的是数组["urgent", "high"]，等值匹配仍可能无法高效利用索引前缀 - 集合开启了通配符索引（
{"$**": 1}）：它会污染优化器决策，导致本该走精确复合索引的查询反而选了低效的通配符路径 - 数据分布极端倾斜：比如
status: "pending"占 95% 文档，那即使有索引，优化器也可能认为全表扫描更快——这时得靠hint()强制，但仅限于find()
最易被忽略的是：索引字段顺序必须严格对应访问模式，少一个等值字段、多一个无关字段，下推就失效。这不是“差不多能用”，而是“差一点就全盘退化”。
