SQL报表高峰需协同缓存与限流：缓存兜底高频低实时性查询（如T+1概览），限流保护强一致敏感请求（如秒级下钻）；分层限流+动态TTL+布隆过滤+多维监控保障稳定性。
SQL报表查询高峰时，数据库容易因并发高、计算重而响应变慢甚至超时。单纯靠限流会丢请求，只依赖缓存又可能数据不准——关键在于让限流和缓存“配合做事”：缓存兜底可服务的查询，限流保护不可缓存或需强一致的请求，二者边界清晰、切换平滑。
明确哪些报表适合缓存，哪些必须走库
不是所有报表都该缓存。高频访问、实时性要求宽松（如T+1经营概览、周同比趋势）且SQL稳定、参数离散度低的，优先缓存；而涉及敏感数据、需精确到秒、参数组合爆炸（如自定义多维下钻）或含用户私有上下文的，应绕过缓存直连数据库，并纳入限流管控。
- 缓存建议用带版本号的键名，例如 report:summary:2024Q3:v2，便于灰度更新与失效
- 对参数化报表（如按部门ID查），可对参数做归一化哈希（如MD5(dept_id + “_2024Q3”)），避免键膨胀
- 直连数据库的请求，必须携带业务标签（如 source=bi_portal, type=ad_hoc），供限流规则识别
分层限流：API网关 + 应用层 + 数据库代理协同
单点限流易被绕过或误伤。应在不同层级设不同粒度策略：
- 网关层：按用户/租户维度限流（如单租户每分钟最多30次报表请求），防恶意刷量
- 应用层：对高成本SQL打标（如含GROUP BY + 多表JOIN + WHERE时间范围＞30天），命中即触发熔断+降级提示
- 数据库代理（如ProxySQL、ShardingSphere）：按SQL指纹限频（如相同执行计划每秒最多5次），从源头压制重复重查询
缓存与限流联动的关键状态设计
缓存不是静态兜底，要感知系统压力动态调整行为：
- 当数据库负载＞80% 或限流触发率连续2分钟＞15%，自动缩短缓存TTL（如从30分钟缩至5分钟），加快数据新鲜度并减轻后端压力
- 缓存穿透场景（大量查不存在的报表ID），启用布隆过滤器前置拦截，并将空结果也缓存短时间（如60秒），避免反复击穿
- 限流拒绝时，返回HTTP 429并附带 Retry-After 和 X-Cache-Hit: false，前端可据此提示用户稍后重试，而非盲目刷新
验证与可观测：不能只看“不报错”，要看“是否合理”
上线后重点监控三类指标交叉分析：
- 缓存命中率（整体 & 各报表类型）是否稳定在预期区间（如>70%）
- 限流拦截数突增时，是否同步出现对应SQL的慢查询日志增多
- 用户端报表平均耗时下降，但“数据已过期”投诉是否上升——说明缓存策略过于激进
不复杂但容易忽略：每次发布新报表，必须同步配置缓存策略和限流白名单，否则上线即成压测靶子。
