mongodb 4.2聚合性能提升源于内存限制放宽、优化器增强及分片事务支持，而非底层引擎飞跃；mapreduce已弃用，应优先使用$graphlookup、分步聚合或应用层处理；真实瓶颈多在$match位置、索引匹配与$unwind滥用。
聚合管道在4.2中比3.2快，但不是因为版本本身“变快”，而是限制放宽+优化增强
MongoDB 4.2 的聚合性能提升，不来自底层引擎的突飞猛进，而在于对 db.collection.aggregate() 的实际执行约束被系统性松动。3.2 中一个常见卡点是：只要单次聚合内存占用超过 20%，就直接报错 errmsg: "aggregation execution failed: Exceeded memory limit"；而 4.2 在 WiredTiger 引擎和更成熟的查询优化器加持下，对内存使用更宽容（尤其配合 allowDiskUse: true），且默认启用更多阶段重排与索引下推逻辑。
这意味着同样一条含 $lookup + $unwind + $group 的管道，在 3.2 上可能因中间结果膨胀而失败，4.2 却能落盘继续执行——不是“算得更快”，而是“终于能算完”。
MapReduce 在 4.2 中已基本弃用，Pipeline 是唯一推荐路径
MapReduce 的设计初衷是应对无法用 Pipeline 表达的复杂逻辑（比如递归图遍历、跨文档状态累积），但它依赖 JavaScript 引擎、无法利用索引、输出必须写入临时集合，且从 3.6 开始已被标记为 deprecated，4.2 完全移除对它的官方支持。现在遇到“Pipeline 写不出来”的需求，正确解法是：
- 用
$graphLookup替代大部分图类递归场景（3.4+ 支持） - 把复杂逻辑拆成多次
aggregate()调用，中间结果存入临时集合（用collation或 TTL 控制生命周期） - 必要时在应用层做二次加工，而非强求数据库完成所有计算
硬上 MapReduce 不仅慢（单机 JS 执行、无并行、无索引），还会让升级到 4.2 后彻底不可用。
真实瓶颈往往不在版本，而在 $match 是否前置 + 索引是否匹配
同一台机器、同一数据集，3.2 和 4.2 跑相同聚合，响应时间差异可能不到 10%，但如果 $match 阶段写在 $lookup 后面，性能差距会拉到 10 倍以上。4.2 的优化器虽能自动将部分 $match 提前，但只对“不依赖投影字段”的条件生效。例如：
db.orders.aggregate([
{ $addFields: { totalWithTax: { $multiply: ["$total", 1.08] } } },
{ $match: { status: "shipped", totalWithTax: { $gt: 100 } } }
])
这个 $match 中的 totalWithTax 是计算字段，优化器无法提前；但 status: "shipped" 可被提到 $addFields 前——手动调整后，就能命中 {status: 1} 索引，大幅减少输入文档数。
所以别迷信版本号，先检查三件事：
- 最外层
$match是否用了索引字段？ - 所有
$lookup的 from 集合是否在本地键上有索引？ - 是否误用了
$unwind导致文档爆炸（比如数组平均长度 50，$unwind后数据量 ×50）？
4.2 的真正优势：分片集群下聚合可跨片事务一致，3.2 不支持
如果你的聚合操作涉及多个分片（比如按用户 ID 分片，但要统计全站订单趋势），3.2 的 aggregate() 在分片集群中本质是“各片独立执行 + 应用层合并”，无法保证读一致性，也完全不支持事务语义；而 4.2 引入二段提交机制，允许你在分片集群上安全地执行带 $transaction 的聚合（需开启 readConcern: "majority"）。这不是性能提升，而是能力跃迁——以前不敢做的聚合，现在敢了。
不过要注意：这种能力只在分片集群 + 显式开启事务时生效，单副本集或 standalone 实例上无区别。升级到 4.2 后若未启用分片事务，聚合行为与 3.2 几乎一致。
