MapReduce在分片集群中更慢，因其默认将所有分片数据拉至mongos节点执行JS逻辑，导致网络开销大、单点资源瓶颈且V8引擎效率低；而聚合管道在满足分片键条件时自动下推至各分片并行执行，性能提升显著。
为什么MapReduce在分片集群里反而更慢
MongoDB的mapReduce命令默认不利用分片的并行能力——它会把所有分片的数据拉到主mongos节点上执行JavaScript逻辑，再汇总结果。这意味着：网络传输量大、单点CPU和内存压力集中、V8引擎执行效率远低于原生C++聚合管道。实测中，1000万文档的去重计数任务耗时1200秒，而同样数据用$group加$count通常在3–5秒内完成。
聚合管道如何自动适配分片集群
只要聚合管道的$match阶段能命中分片键（shard key），整个管道就会被下推到各分片本地执行；后续$group、$sort等操作也尽可能在分片上完成，仅最后的合并阶段由mongos协调。这不是配置项，是MongoDB 3.2+之后的默认行为。
关键条件有三个：
-
$match必须包含分片键的等值查询（如{shard_key: "abc"}），范围查询（如{shard_key: {$gt: 10}}）也能下推，但效果略弱 - 避免在
$group中使用$sum以外的复杂JS逻辑——聚合管道不支持自定义函数 - 确保分片键选择合理：如果
dim0就是你的分片键，那db.uniques.aggregate([{$group: {_id: "$dim0", count: {$sum: 1}}}])就能直接跑满所有分片CPU
从MapReduce迁移到聚合管道的实操要点
迁移不是简单替换语法，要检查三类兼容性断点：
- 原来
map里用emit(key, {a:1, b:2})？聚合里得拆成{$addFields: {a: 1, b: 2}}或用$let构造对象 - 原来
reduce里做数组拼接或去重？聚合里没有等价原语，得用$push+$reduce（4.4+）或改用$addToSet，但要注意内存限制（allowDiskUse: true必须显式开启） - 原来输出到新集合用
out: "mrout"？聚合里对应{$merge: {into: "mrout"}}或{$out: "mrout"}，后者会覆盖全量，前者支持upsert逻辑
示例对比：
db.uniques.mapReduce(
function() { emit(this.dim0, 1); },
function(key, values) { return Array.sum(values); },
{ out: "mrout" }
)
→ 等价聚合写法：
db.uniques.aggregate([
{ $group: { _id: "$dim0", count: { $sum: 1 } } },
{ $out: "mrout" }
], { allowDiskUse: true })
聚合管道仍卡住？先查这三件事
聚合快≠一定快，以下情况会让它退化回单点执行：
- 没建索引：即使
$match用了分片键，也要在该字段建索引，否则分片无法快速定位数据块 - 用了
$unwind后跟$group且数组过大：触发内存限制报错Sort exceeded memory limit，必须加{ allowDiskUse: true } - 分片键设计失衡：比如用时间戳作分片键，导致新数据全写入一个分片，其他分片闲置——这时聚合再并行也没用
真正影响性能的往往不是语法转换，而是分片键是否承载了实际查询模式。别急着重写代码，先用explain("executionStats")看聚合是否真的分发到了多个分片。
