$sort阶段不走索引，必须全量加载内存排序；副本集不改变该逻辑，真正解法是前置$match过滤并用find().sort()替代或严格控制上游文档量。
聚合管道 $sort 阶段不走索引，全靠内存硬扛
副本集本身不改变 $sort 的执行逻辑——MongoDB 聚合管道中的 $sort 阶段**完全不利用任何索引做排序**，无论主节点还是从节点。它会先把上游阶段输出的所有文档加载进内存，再按指定字段比较、重排。这意味着：只要上游结果集大（比如 $match 没命中索引，或没加 $limit），$sort 就立刻变成内存黑洞。
典型错误现象：
"Sort operation used more than the maximum 104857600 bytes of RAM"- 聚合耗时陡增，CPU 和内存使用率飙升
- 在副本集上，从节点同步延迟可能因该查询阻塞而加剧
为什么不能像 find().sort() 那样用索引加速？
MongoDB 查询引擎对 find().sort() 和聚合管道的 $sort 采用两套调度机制：find().sort() 可被查询优化器识别为“排序可下推”，从而尝试复用索引顺序；但 $sort 是聚合阶段，属于独立运算单元，不参与索引选择逻辑。
关键区别：
-
find({ status: "done" }).sort({ createdAt: -1 })→ 可用{ status: 1, createdAt: -1 }索引直接 IXSCAN 输出有序结果 -
aggregate([ { $match: { status: "done" } }, { $sort: { createdAt: -1 } } ])→ 即使有同名索引，$sort仍强制读取全部匹配文档再内存排序
这不是副本集的限制，而是聚合管道的设计约束——哪怕你在单节点上跑，结果也一样。
副本集环境下更危险的三个放大点
主节点还能靠 allowDiskUse: true 缓一缓，但在副本集里，这个“缓”字容易误判：
- 从节点无法执行
allowDiskUse: true—— 它只回放 oplog，不运行聚合命令，所以主节点上能跑通的带磁盘排序的聚合，在从节点故障恢复或重新同步时可能卡死 - oplog 中记录的是原始写操作，不是聚合结果；如果业务依赖聚合输出做后续判断（如告警），而该聚合因未索引排序失败，整个链路就断了
- 副本集选举期间，若主节点正被一个巨型
$sort拖垮，可能触发不必要的 failover
真正有效的解法只有两个方向
别指望副本集配置能绕过这个限制，必须从数据流源头控制：
- 把排序逻辑尽量前移到
$match后的索引覆盖查询中：先用find().sort().limit()拿到有序小结果集，再喂给聚合做后续加工 - 在聚合内部，用
$addFields+$sort前，确保上游已通过$limit或强条件$match把文档数压到几千以内（例如{ $limit: 1000 }） - 绝对避免在聚合末尾才
$sort—— 那等于把所有中间结果都攒起来再排，最容易爆内存
最常被忽略的一点：即使你给排序字段建了索引，只要它出现在聚合管道里，就对 $sort 阶段零作用。索引只服务于查询层，不透传给聚合引擎。
