直接高频更新字段会导致性能问题，因MongoDB文档体积增大时需重定位并更新索引，引发碎片、写放大和锁竞争，同时频繁$inc+find及聚合操作加剧响应延迟。
为什么直接高频更新字段会导致性能问题
MongoDB 对文档的原地更新（in-place update）有严格限制：当更新后文档体积超过原大小，就必须触发 document relocation——即把整个文档挪到新位置，并更新所有相关索引条目。高频更新如 view_count、last_active_at、score 等字段，极易引发碎片、写放大和锁竞争。
更关键的是，这类字段常被用于排序、分页或实时展示，导致应用层频繁发起 $inc + find() 组合操作，同时聚合管道里反复 $sum 或 $max，进一步拖慢响应。
实际中你可能已遇到：WriteConflict 报错增多、wt_cache_overhead 持续偏高、或者 explain("executionStats") 显示大量 docsExamined 远大于 nReturned。
Computed Pattern 的核心做法：把“值”变成“表达式”
不存实时值，而是存触发计算的原始事件或因子，用轻量级字段标记状态，在读取时按需合成结果——本质是用空间换原子性，用延迟计算换写入吞吐。
比如将 total_likes 字段移除，改存：
-
like_events: [{ user_id: "u123", at: ISODate("...") }]（事件列表，加 TTL 索引自动清理）
-
like_count_snapshot: 42（最近一次快照值，带 snapshot_at 时间戳）
-
is_computed_stale: true（布尔标记，表示快照是否过期）
like_events: [{ user_id: "u123", at: ISODate("...") }]（事件列表，加 TTL 索引自动清理）like_count_snapshot: 42（最近一次快照值，带 snapshot_at 时间戳）is_computed_stale: true（布尔标记，表示快照是否过期）读取时逻辑变为：
if (!doc.is_computed_stale) {
return doc.like_count_snapshot;
} else {
const fresh = doc.like_events.length + doc.like_count_snapshot;
// 可选：异步更新快照 & 标记为 false
return fresh;
}
什么时候该用预计算而非纯实时聚合
不是所有场景都适合 Computed Pattern。判断依据看三个信号：
- 写入 QPS > 50/s 且单文档更新占比高 → 必须剥离
- 读取路径中
$group / $sum 出现在高频接口（如首页 Feed）→ 预计算能降 70%+ 聚合耗时
- 业务允许秒级延迟（比如“最新点赞数”显示滞后 2–3 秒可接受）→ 就具备落地前提
$group / $sum 出现在高频接口（如首页 Feed）→ 预计算能降 70%+ 聚合耗时注意：若字段参与 sort() 或 skip()/limit()，必须确保快照值可建索引；like_count_snapshot 要加 { like_count_snapshot: 1 } 单字段索引，否则分页会退化为内存排序。
容易忽略的边界与维护成本
Computed Pattern 不是“设完就不管”。最常漏掉的是：
- 未对
like_events 设置 TTL 索引 → 历史事件无限堆积，查询变慢甚至 OOM
- 快照更新逻辑放在应用层但没做幂等 → 多实例并发触发重复写入，导致计数漂移
- 忘记在写事件时同步更新
is_computed_stale → 读永远走旧快照，数据看似“稳定”实则错误
- 聚合管道里仍保留冗余
$sum 计算 → 白费力气，要彻底删掉旧逻辑
like_events 设置 TTL 索引 → 历史事件无限堆积，查询变慢甚至 OOMis_computed_stale → 读永远走旧快照，数据看似“稳定”实则错误$sum 计算 → 白费力气，要彻底删掉旧逻辑真正省下的不是代码行数，而是对“一致性”边界的清醒认知：你不再追求强实时，而是明确知道 stale window 是多少、谁负责刷新、失败后怎么兜底。这点比任何模式都难落实。
