MongoDB缓存各集合唯一查询count()结果的存储最佳实践

核心结论 #

优先选择新建独立集合统一存储所有count缓存，不要把缓存数据塞进对应业务集合。

为什么不推荐存业务集合 #

• 职责不匹配：业务集合存储的是核心业务实体数据，count缓存是和特定查询条件绑定的派生数据，和单条业务文档的属性没有直接关系，混存会直接污染业务文档结构，后续迭代时极易混淆业务字段和缓存字段，提升维护成本。
• 可行性极低：单个业务集合往往对应几十上百种不同查询条件的count需求，你不可能为每一种查询在每一条业务文档上加对应的缓存字段——这会带来天量的数据冗余，更新缓存时需要遍历全量文档修改，完全失去缓存提速的意义。
• 风险不可控：业务集合本身承载核心读写流量，把缓存逻辑耦合进去后，缓存更新的bug、额外的读写开销都可能直接影响核心业务的稳定性。

独立缓存集合的设计参考 #

新建专门的缓存集合（例如命名为query_count_cache）是这类场景的通用最佳实践，单条文档结构建议如下：

{
  "_id": "col1_a1b2c3d4", // 组成规则：目标集合名_查询条件标准化后的哈希值
  "target_col": "col1",
  "query_hash": "a1b2c3d4",
  "query_content": { "status": 1, "type": "news" }, // 原始查询条件，留作排查问题用
  "count_val": 890,
  "expire_time": ISODate("2024-06-10T00:00:00Z"), // 缓存过期时间
  "last_update": ISODate("2024-06-03T00:00:00Z")
}

这个方案的优势非常明确：

• 完全隔离：缓存数据和业务数据物理分离，缓存逻辑的任何问题都不会污染核心业务数据
• 性能足够：_id字段自带唯一主键索引，查询缓存时是O(1)级别的精确匹配，速度远高于在业务集合中检索
• 易维护：直接给expire_time字段加TTL索引，就能自动过期删除冷缓存，不需要额外开发清理逻辑；后续要加命中率统计、手动失效、分级过期策略都可以直接在这个集合上扩展，完全不影响业务集合
• 适配性强：不管后续新增多少个业务集合、多少种查询条件，都可以用同一套逻辑管理缓存，不需要重复改多个业务集合的结构

落地注意事项 #

• 生成缓存key的时候，一定要先对查询条件做标准化处理：把查询对象的key按固定顺序排序后再序列化计算哈希，避免同一个查询因为字段书写顺序不同被识别成不同key，生成重复缓存条目
• 不要追求缓存的强一致：count查询本身对实时性的容忍度通常较高，建议采用「过期兜底+写操作异步触发失效」的策略更新缓存，不要在业务写流程里同步执行count计算，避免拖慢核心写性能
• 如果有部分查询条件完全固定、访问频率极高（比如全表有效文档总数），也可以单独维护更轻量的专用计数器，但通用场景下的任意查询count缓存，独立集合方案的投入产出比最高。

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