报表高峰压力源于查询请求时间扎堆，削峰缓存通过预计算汇总表、分级缓存+语义化Key、写时失效为主+读时校验、清理无效流量及优化索引来应对。
报表高峰带来的数据库压力，本质是“查询请求在时间上扎堆”，不是单次查询慢，而是单位时间内请求太多。削峰缓存策略的核心，就是把原本集中涌向数据库的请求，分散成“查一次、用多次”，同时让部分请求根本不用查。
按业务节奏预计算汇总表
高频访问的聚合结果（比如“各城市昨日销售额”“各品类周转化率”）不该每次实时算。应结合业务周期，在低峰期（如凌晨2点）通过定时任务跑批，把结果写入轻量汇总表。这张表字段精简、带分区（如 dt='20260310'）、有联合索引（如 city, category），报表直接查它，响应从秒级降到毫秒级。
分级缓存+语义化Key设计
不是所有报表都该用同一种缓存方式：
- 静态配置类（如地区字典、状态枚举）：用长 TTL（1小时以上），支持主动刷新
- 主键明确的明细查询（如 SELECT * FROM report_task WHERE id = 123）：缓存 Key 设为 report_task:123，DB 写完立刻删对应 Key
- 带参数的聚合查询（如 “近30天各渠道订单数”）：不缓存 SQL 结果，改用预计算表 + 时间范围参数拼 Key，例如 report:channel_order:20260211_20260310
Key 必须带业务前缀、关键参数签名，不拼原始 SQL；分页类查询要把 page 和 size 显式纳入 Key，避免第一页缓存被误用于其他页。
读写协同的失效机制
缓存脏数据多因失效滞后。必须以“写时失效”为主：事务提交后立即删除或更新相关缓存。对无法精准定位影响范围的场景（如批量更新订单状态），可配合“读时校验”——缓存中存版本号或更新时间戳，读取时比对 DB 当前值，不一致则异步刷新。纯靠 TTL 容易引发雪崩，建议加 ±5% 随机偏移。
清理无效流量源头
很多高峰压力来自“没人管”的查询：
- 已下线报表仍被旧定时任务调用
- 前端监控脚本每5秒轮询一次日报接口
- 测试环境未关闭的压测脚本
定期审计 slow query 日志和调度系统，识别并下线这些无效调用。同时检查索引有效性：删掉重复或前缀重叠的索引，对常用 WHERE + ORDER BY 组合建联合索引（如 (status, created_at)）。
