MongoDB 4.2中聚合与查询排序的内存排序差异疑问

场景复现 #

在MongoDB v4.2环境中，集合surveys仅存在_id索引，插入测试数据：

db.surveys.insertMany([
    {_id:"A1", from_uid:NumberInt(100), to_uid:NumberInt(200), time:NumberInt(1234)}, 
    {_id:"A2", from_uid:NumberInt(100), to_uid:NumberInt(300), time:NumberInt(1231)}, 
    {_id:"A3", from_uid:NumberInt(300), to_uid:NumberInt(200), time:NumberInt(1230)}, 
    {_id:"A4", from_uid:NumberInt(100), to_uid:NumberInt(201), time:NumberInt(1231)}, 
    {_id:"A5", from_uid:NumberInt(100), to_uid:NumberInt(202), time:NumberInt(1235)}, 
])

执行两条带explain(true)的语句：

db.surveys.aggregate([{"$match":{"from_uid":100}},{"$sort":{"time":-1}}]).explain(true)  
db.surveys.find({"from_uid":100}).sort({"time":-1}).explain(true)

观察到：

• 聚合语句的explain结果中Sorted in Memory为false
• find+sort语句的explain结果中Sorted in Memory为true

差异原因解析 #

1. 聚合管道$sort的小数据优化逻辑 #

MongoDB 4.2的聚合管道优化器针对极小数据集做了特殊处理：当$match阶段仅返回少量文档（本例为4条），$sort会直接在获取文档后执行轻量级排序，无需启用完整的内存排序机制，因此Sorted in Memory标记为false。

2. find+sort的标记规则更直白 #

find命令的sort操作，只要没有匹配的复合索引（如{from_uid:1, time:-1}）支持排序，无论返回文档量大小，都会明确标记Sorted in Memory: true。其标记逻辑核心是：只要不是通过索引顺序获取已排序结果，就判定为内存排序。

3. 底层执行引擎的路径差异 #

聚合管道和find命令使用不同的底层执行路径：

• 聚合管道拥有独立优化器，会根据数据量动态调整排序策略，小数据量下简化流程，不标记内存排序。
• find命令的排序逻辑更偏向直接反映索引依赖情况，无索引支持时，无论数据量大小都会标记为内存排序。

内容的提问来源于stack exchange，提问作者upuppanda