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 的慢查询日志增多
- 用户端报表平均耗时下降，但“数据已过期”投诉是否上升——说明缓存策略过于激进
不复杂但容易忽略：每次发布新报表，必须同步配置缓存策略和限流白名单，否则上线即成压测靶子。
