在处理大量数据的数学运算（如求和）时，应优先利用数据库内置的聚合能力（如 MongoDB 的 $sum），而非在应用层遍历文档计算——这能显著降低网络传输开销、内存占用与执行时间，并通过复合索引实现近乎纯内存级的高效运算。
在处理大量数据的数学运算（如求和）时，应优先利用数据库内置的聚合能力（如 mongodb 的 `$sum`），而非在应用层遍历文档计算——这能显著降低网络传输开销、内存占用与执行时间，并通过复合索引实现近乎纯内存级的高效运算。
当需要对成百上千甚至百万级文档执行汇总计算（例如按字段分组求和），服务端聚合永远优于客户端循环。原因在于：
-
数据传输成本：
find()拉取全部文档会触发完整 BSON 序列化、网络传输与 PHP 对象反序列化，而聚合仅返回轻量结果（如{ _id: "A", result: 12345 }）； -
内存压力：PHP 循环需将全部文档载入内存，易触发
memory_limit错误；聚合由数据库引擎在服务端流式处理，内存占用恒定； - 执行效率：MongoDB 聚合管道可深度优化，配合复合索引甚至无需读取原始文档。
✅ 正确做法：使用带索引支持的聚合查询
首先创建覆盖索引（Covered Index），确保聚合所需字段全部包含在索引中：
db.collection.createIndex({ "fieldOne": 1, "fieldTwo": 1 });然后执行聚合，并显式 hint() 引导查询优化器使用该索引（⚠️ 注意：$group 阶段默认不自动选择索引，必须手动提示）：
db.collection.explain("executionStats").aggregate([
{ $group: { _id: "$fieldOne", result: { $sum: "$fieldTwo" } } }
], { hint: { "fieldOne": 1, "fieldTwo": 1 } });若执行计划中出现 "totalDocsExamined" : 0 且 "executionTimeMillis" 极低（如 ），即表明数据库完全通过索引完成计算，未触碰磁盘文档——这是性能最优状态。
❌ 反模式示例（应避免）：
// ❌ 危险：全量拉取 + 内存遍历 → 网络/内存/时间三重浪费
$result = $db->collection->find([]);
$sum = 0;
foreach ($result as $doc) {
$sum += $doc->fieldTwo ?? 0; // 还需空值防护
}? 关键提醒：
- 索引字段顺序很重要：
{fieldOne: 1, fieldTwo: 1}支持按fieldOne分组 + 对fieldTwo求和；若顺序颠倒则无法覆盖； -
hint()不是可选优化项，而是$group + $sum场景下的必要显式声明； - 对于实时性要求不高或需复杂业务逻辑的场景，可考虑预聚合（如定时任务写入汇总表），但绝不在热路径上做客户端循环。
总之：把计算留给数据库，把展示留给应用——这是高并发、大数据量场景下不可动摇的最佳实践。
