报表统计结果缓存的核心目标是平衡实时性、一致性与性能，需按业务语义分级设计策略：静态维度表用长TTL+主动刷新，业务主键聚合用语义化Key精准失效，动态时间窗口推荐预计算+版本化存储；Key须含业务域、口径、粒度及租户标识，禁用明文敏感信息；失效以写时清理为主、读时校验为辅；关键报表结果应落库持久化，缓存仅存元数据，形成“缓存-报表库-实时计算”闭环。
报表统计结果缓存的核心目标是平衡实时性、一致性与性能——它不是简单地“把SQL结果存起来”，而是针对聚合类、分析类查询的特征，设计可管理、可预测、可兜底的持久化路径。
按业务语义分级缓存，不一刀切
统计类查询差异极大，缓存策略必须区分对待：
- 静态维度表统计（如：各城市订单量月度汇总）→ 数据更新频率低（每月/每周跑批），适合长 TTL（24 小时以上），配合调度系统主动刷新或监听 ETL 完成事件触发缓存更新
- 业务主键聚合（如：SELECT SUM(amount) FROM order WHERE user_id = ? AND status = 'paid'）→ 按 user_id + status 构建语义化 Key（如 report:user:sum:paid:10086），DB 写入后精准删除对应 Key，避免全表失效
- 动态时间窗口聚合（如：近7天日活、滚动30天销售额）→ 不建议直接缓存原始结果；推荐预计算+版本化存储：将结果写入专用报表宽表（如 rpt_daily_active_7d），缓存中只存该宽表的最新更新时间戳，读取时校验时间戳再决定是否回源
Key 设计要支持运维和隔离
缓存 Key 是缓存治理的入口，不能仅靠 SQL 哈希：
- 包含业务域+统计口径+时间粒度，例如：report:order:revenue:daily:20260312，而非 md5("SELECT SUM...")
- 多租户系统必须嵌入 tenant_id，如 report:tenant:abc123:order:count:monthly
- 测试环境加 test_ 前缀，上线前自动替换，防止误刷生产缓存
- 敏感维度（如用户手机号、设备 ID）禁止明文入 Key，改用脱敏 ID 或哈希摘要（如 sha256(phone)[:8]）
失效机制以写时清理为主，读时校验为辅
统计结果缓存最怕脏数据，失效逻辑必须严格对齐数据源头：
- 所有影响报表数据的写操作（含批量导入、状态变更、对账修正），必须在事务提交后触发对应 Key 删除，不可在事务内或回滚前执行
- 对时效性要求中等的报表（如 T+1 日报），可在读取时比对源表最大更新时间（如 MAX(updated_at)）与缓存中记录的 last_refresh_time，偏差超阈值则异步刷新并返回旧数据
- 禁止单纯依赖 TTL 驱逐——尤其在凌晨批量刷新时段，集中过期易引发数据库回源风暴；建议叠加 ±10% 随机偏移
落库+缓存双写，构建持久化基线
关键报表结果不应只存在内存缓存中：
- 将每日/每小时生成的统计结果写入专用报表库（如 PostgreSQL 的 rpt_summary 表），带 version、created_at、source_job_id 字段
- 缓存中只存轻量元数据（如 {“value”: 124890, “version”: 2026031202, “updated_at”: “2026-03-12T23:59:58Z”}），真正大结果集由缓存指向数据库中的物理行
- 当缓存失效或缺失时，优先查报表库；若无记录，再触发实时计算并写回双端，形成闭环
不复杂但容易忽略。关键在于把“缓存”当成报表交付链路的一环，而不是临时加速技巧。
