多行/文档求和等运算：数据库查询与代码循环哪个是最佳实践？

绝大多数场景下，优先使用数据库内置的聚合计算能力完成运算，绝对不要默认写代码拉全量数据循环遍历计算。

两种方案的核心差异 #

1. 数据库端计算的优势 #

数据库本身就是为数据存取、计算优化的组件，直接在库内完成聚合的收益非常明显：

• 省掉海量网络IO开销：不需要把全量数据从数据库服务器通过网络传输到应用服务器，数据量越大，这部分的耗时占比越高——上T级数据光传输就要几十分钟，更别说后续计算。
• 计算效率更高：不管是MongoDB的聚合管道，还是MySQL这类关系库的聚合函数，都是底层用高性能语言实现的原生逻辑，比PHP、Python这类应用层语言的循环计算效率高一个量级以上，还能直接利用索引加速过滤、分组流程，有索引的场景下甚至不需要扫全表就能出结果。
• 资源占用更可控：数据库聚合支持流式计算，不会把全量数据一次性加载到内存，不会出现应用侧拉全量数据直接打满内存报OOM的问题，也不需要额外写游标分批拉取、内存释放的容错代码。

MongoDB 分组求和示例：

db.collection.aggregate([
  {$group:{_id:"$fieldOne",result:{$sum:"$fieldTwo"}}}
])

2. 应用层循环计算的适用场景 #

只有当计算逻辑极度复杂，数据库的聚合语法、自定义函数完全无法实现的时候，才考虑拉数据到应用层计算——比如计算过程需要结合外部业务规则、调用第三方服务接口做动态判定、运算逻辑包含数据库不支持的特殊算法。
就算必须在应用层算，也一定要先在数据库侧做预过滤、预聚合，只拉取计算必须的字段和数据行，绝对不要直接全表查所有数据拉回来。

不推荐的全量拉取循环写法（PHP）：

$result = db['myDb']->collection->find([]);
$sum = 0;
foreach($result as $doc) {
   $sum += $doc->fieldTwo;
}

这个写法在数据量超过10万条时就会出现明显的性能下滑，百万级以上数据基本会直接拖垮接口响应，还会占满数据库的出口带宽，影响其他业务请求。

落地注意事项 #

• 不管用哪种方案，聚合计算时只取需要的字段，不要把文档里无关的大字段（长文本、二进制附件、冗余内容）带出来，避免无意义的资源消耗
• 聚合用到的分组、过滤条件字段，提前建好对应索引，能把聚合速度提升几个数量级
• 单表千万级以上的超大数据集，不要在业务高峰期跑实时聚合，可以提前做预计算结果表，或者走离线数仓跑批生成结果

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