SQL报表同比环比计算慢的核心问题是重复扫描历史数据与缓存机制缺失；需分层缓存高频低更、高开销、维度固定的指标，结合物化视图/预聚合表与带时间语义的应用层缓存，并辅以SQL轻量优化。
SQL报表中同比、环比计算慢，核心问题往往不是SQL写法本身，而是重复扫描大量历史数据 + 缺乏有效缓存机制。指标缓存不是简单加个Redis，而是要分层设计、按需预热、精准失效。
明确哪些指标适合缓存
不是所有指标都值得缓存。优先缓存：
- 高频访问 + 低更新频次：如“昨日销售额”“上月订单量”，每天只变1次，但被上百张报表调用
- 计算开销大 + 依赖宽表：涉及多表JOIN、窗口函数（如LAG/LEAD）、日期偏移（DATE_SUB）的同比逻辑
- 维度固定、参数有限：比如只按“省份+品类”聚合，且查询参数只有5种组合，缓存成本低、命中率高
用物化视图或预聚合表替代实时计算
数据库原生支持比应用层缓存更稳定、一致性更好：
- MySQL 8.0+ 可建汇总表 + 定时任务刷新（如每晚2点跑ETL，生成daily_sales_summary）
- ClickHouse 直接用MATERIALIZED VIEW自动维护环比字段（如sales_lag7 = lagInFrame(sales, 7)）
- Doris 支持Rollup表，对常用group by维度提前聚合，查同比时只需扫小表
应用层缓存要带“时间语义”和“维度签名”
避免缓存键设计太粗放（如只缓存"sales_yoy"），导致不同日期/部门请求互相污染：
- 缓存key示例：report:sales:yoy:20240601:shanghai:electronics
- 设置TTL略长于更新周期（如日报表缓存26小时），并配合主动失效（ETL成功后删对应key）
- 首次查询未命中时，走预聚合表而非原始明细表，降低穿透压力
SQL层面做轻量优化（不改架构也能提效）
在无法立刻上缓存时，快速见效的写法调整：
- 把子查询中的日期计算提到WITH中，避免每行重复算DATE_SUB(NOW(), INTERVAL 1 MONTH)
- 用LEFT JOIN同构汇总表代替多次SELECT子查询查去年同期（减少IO和执行计划复杂度）
- 对分区表确保WHERE条件能命中分区键（如PARTITION BY ds），避免全分区扫描
