根本原因是secondary节点默认禁用allowdiskuse且缓存较冷，导致排序时更易触达100mb内存限制；必须显式添加allowdiskuse:true并优化索引与负载分布。
从节点执行聚合排序时触发 Sort exceeded memory limit of 104857600 bytes，根本原因不是“从节点特殊”，而是它默认禁用磁盘辅助排序（allowDiskUse），且副本集架构下读操作常被路由到 secondary —— 这个组合让问题更易暴露。
为什么 secondary 聚合更容易报这个错
副本集的 secondary 节点默认开启 readPreference=secondary 时，应用可能把带 $sort 的聚合发到从节点；而 MongoDB 在 6.0 以下版本中，allowDiskUse 默认为 false，且该选项**必须显式传入聚合命令**，不会因节点角色自动启用。secondary 上没有写压力，但缓存可能更“冷”，排序时更依赖内存加载全量数据，反而比 primary 更早触达 100MB 限制。
- 聚合命令未加
allowDiskUse: true，secondary 不会自动 fallback 到磁盘 - secondary 的
wiredTiger.cache可能因只读负载不活跃，导致排序中间结果无法有效复用缓存页 - 如果聚合里有
$lookup或多阶段$unwind，secondary 上缺少写路径的预热机制，内存分配更激进
聚合命令必须显式加 allowDiskUse: true
这是最直接有效的修复动作，不依赖节点角色或版本（只要 ≥ 3.2）。注意：它只对当前聚合生效，不能全局开关。
- Node.js 驱动示例：
collection.aggregate(pipeline, { allowDiskUse: true }) - Mongo Shell 示例：
db.orders.aggregate([ { $sort: { createdAt: -1 } } ], { allowDiskUse: true }) - Java 驱动需用
AggregateIterable#allowDiskUse(true)，不是配置项 - 若用 Spring Data MongoDB，需在
@Aggregation注解外包裹AggregationOptions.builder().allowDiskUse(true).build()
secondary 上不能只靠加 allowDiskUse 就高枕无忧
磁盘排序虽能绕过内存限制，但在 secondary 上代价更高：它会占用本地 /tmp 或 storage.dbPath/_tmp 空间，且 IO 延迟直接影响查询 P99。尤其当多个聚合并发执行时，临时文件竞争会导致响应毛刺。
- 检查
db.serverStatus().metrics.queryExecutor.scannedObjects，若远大于nReturned，说明排序前扫描了大量无关文档 —— 应优先加索引，而非依赖磁盘 - secondary 的
storage.wiredTiger.engineConfig.cacheSizeGB若设得太小（如仅 2GB），即使开了allowDiskUse，WiredTiger 仍会频繁驱逐缓存页去腾出内存给排序上下文，加剧 IO - 确认
maxCacheOverflowFileSizeGB（4.4+）未被设为 0 —— 它控制单个临时排序文件上限，设为 0 会禁用磁盘排序，使allowDiskUse失效
别忽略 readPreference 和负载分布的副作用
很多团队把聚合发到 secondary 是为了分担 primary 压力，但没意识到：secondary 的硬件规格、IO 能力、甚至磁盘类型（比如用 SATA 盘跑临时排序）可能远弱于 primary。一旦开启 allowDiskUse，瓶颈就从内存转移到磁盘。
- 如果业务允许，把重排序聚合固定发到
primary（readPreference=primary），利用其更强的缓存热度和 SSD 性能 - 若必须走 secondary，请确保其
storage.dbPath所在磁盘是独立 SSD，且/tmp挂载在相同设备上（避免跨盘 IO） - 监控
db.currentOp({ "secs_running": { "$gt": 5 }, "active": true })中状态为EXECUTING_SORT的操作，它们正是磁盘排序的候补者
真正麻烦的不是报错本身，而是把 allowDiskUse: true 当成万能膏药后，忽略了 secondary 上缺乏写负载导致的缓存失温问题——它会让排序更慢、更吃磁盘，而你可能只盯着错误是否消失。
