MongoDB聚合管道中动态新增字段的排序优化问题

针对你的场景（仅464个文档但排序耗时60秒），以下是无需大幅修改原有管道逻辑的优化方案：

1. 合并$addFields步骤 #

当前管道用了两次独立的$addFields生成字段，MongoDB需要遍历两次所有文档并重新构造文档结构。合并成单个$addFields可以减少一次全量遍历，降低计算开销：

[... 其他步骤 ...
{ '$addFields': { 
    'list.a_new_field': { ... },
    'list.other_new_field': { '$sum': [ { '$max': '$list.a_new_field' } ] }
} },
{ '$sort': { 'list.other_new_field': -1 } },
... 其他步骤 ...
]

2. 简化冗余的聚合表达式 #

你的list.other_new_field用$sum包裹$max是冗余的——$max返回单个数值，$sum单个数值的结果等于该数值本身。直接替换为$max可以减少一层计算，完全不改变字段最终值，却能大幅降低计算耗时：

{ '$addFields': { 
    'list.a_new_field': { ... },
    'list.other_new_field': { '$max': '$list.a_new_field' }
} }

3. 提前过滤与裁剪数据 #

如果管道前序步骤没有做数据过滤，在$addFields之前添加$match过滤掉不需要的文档；同时用$project只保留后续步骤必须的字段（比如原文档中与list.a_new_field计算、排序无关的字段可以暂时剔除），减少每个文档的体积，让排序时内存使用更高效：

[... 其他步骤 ...
{ '$match': { /* 过滤条件，只保留需要处理的文档 */ } },
{ '$project': { 'list': 1, /* 其他必须保留的字段 */ } },
{ '$addFields': { /* 合并后的字段生成逻辑 */ } },
{ '$sort': { 'list.other_new_field': -1 } },
... 其他步骤 ...
]

4. 确保排序使用内存而非磁盘 #

虽然集合文档数量少，但如果单个文档体积过大，$sort可能会触发磁盘排序（远慢于内存排序）。可以在聚合时开启allowDiskUse: true作为兜底，但更优先的是通过前面的字段裁剪减少文档大小，让排序完全在内存中完成。

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