$sort在副本集中仍慢，因需同时满足索引覆盖与管道结构匹配：$sort须紧接$match后，$match字段须为复合索引前缀，$sort字段须为索引连续后缀，且索引顺序须为等值→范围→排序。
为什么$sort在副本集里还是慢，即使建了索引？
不是索引存在就能加速 $sort，而是必须满足「索引覆盖 + 管道结构匹配」两个硬条件。副本集本身不改变优化逻辑，但主节点执行时若未触发索引下推，从节点同步的仍是全量未排序数据，查询延迟和内存压力照旧。常见现象是 executionStats 里 totalDocsExamined 远大于 nReturned，且 sortStage 显示 memUsage 飙升——这说明排序仍在内存中做，索引没被真正利用。
$sort 要想走索引下推，管道写法必须严格满足这几点
MongoDB 6.0 的聚合索引下推（Pipeline Index Pushdown）只对特定结构生效，错一个就退化为内存排序：
-
$sort必须紧接在$match之后，中间不能插$project、$addFields、$set等字段变换阶段 -
$match条件字段必须构成复合索引的前缀，例如索引是{status: 1, createdAt: -1, _id: 1}，那么$match: {status: "active", createdAt: {$gte: ISODate("2024-01-01")}}可下推；但只写$match: {createdAt: {$gte: ...}}就不行 -
$sort字段必须是该索引的**连续后缀**，比如上例中{$sort: {createdAt: -1, _id: 1}}可下推，但{$sort: {_id: 1}}单独用就不行 - 不要显式加
allowDiskUse: true——它可能干扰优化器判断，哪怕你预估会超内存
怎么验证 $sort 真的走索引了？
运行带 .explain("executionStats") 的聚合，重点看 executionStages：
- 如果看到
IXSCAN阶段直接输出已排序文档，且后续没有sortStage，或sortStage中works: 0，说明下推成功 - 如果仍有
sortStage且memUsage > 0，说明还在内存排序，得回头检查管道结构或索引定义 - 注意：副本集里要连主节点查
explain，从节点不执行聚合优化决策
复合索引设计必须按「等值 → 范围 → 排序」顺序
索引字段顺序不是随便排的，它直接决定能否覆盖 $match + $sort 组合：
- 等值字段放最前：
$match: {status: "active"}→ 索引第一项必须是status: 1 - 范围字段居中：
$match: {createdAt: {$gte: ...}}→ 索引第二项对应createdAt: 1或-1 - 排序字段放最后，方向必须与
$sort一致：$sort: {score: -1, _id: 1}→ 索引末尾就得是score: -1, _id: 1 - 示例完整索引：
db.orders.createIndex({status: 1, createdAt: 1, score: -1, _id: 1})
最容易被忽略的是：即便所有字段都建了单字段索引，只要没按这个联合访问模式建复合索引，$sort 就不会下推。副本集里主节点的查询计划不会“自动拼凑”多个索引。
