跨年sql报表慢的核心原因是数据分布与访问路径不匹配：时间分区粒度粗、聚合索引缺失、跨年查询优化器执行计划不稳定；应按月/周分区、建覆盖过滤与分组字段的复合索引，并用union all拆分跨年查询。
跨年SQL报表慢，核心问题往往不在SQL写法本身，而是数据分布与访问路径没对齐——时间分区没用好，聚合索引缺失，导致扫描量爆炸。
时间分区必须按查询模式对齐
很多系统按年或月建分区，但报表常查“过去12个月”或“FY2023-FY2024”，跨两个年份分区。如果只按年分区（如 p_2023、p_2024），查询 2023-06 至 2024-05 就会强制扫描两个大分区，且无法裁剪掉无效月份。
- 推荐按月或周粒度分区，配合
PARTITION BY RANGE (DATE)，让优化器能精准定位6–12个分区而非2个 - 确保分区键是查询中
WHERE直接过滤的列（如stat_date），避免函数包裹（WHERE YEAR(stat_date)=2024会失效） - 定期检查
EXPLAIN PARTITIONS，确认实际访问的分区数是否合理
聚合索引要覆盖高频统计维度
报表常见“按部门+产品线+月份汇总销售额”，若只在stat_date建单列索引，MySQL仍需回表读取部门、产品等字段再分组，I/O和CPU双高。
- 建复合索引时，把过滤字段放前，分组字段居中，聚合字段放后。例如：
INDEX(stat_date, dept_id, product_line, amount) - 对SUM/COUNT类聚合，可考虑物化聚合表：每天凌晨跑一次
INSERT INTO rpt_daily_summary SELECT dept_id, product_line, DATE(stat_date), SUM(amount) ... GROUP BY ...，报表直接查这张轻量表 - 避免在索引字段上做计算或隐式转换（如
WHERE dept_id + 0 = 1001），会导致索引失效
跨年窗口别硬扛，用UNION ALL分拆更稳
当优化器对跨年范围查询的执行计划不稳定（比如有时走索引有时全扫），与其调优一条复杂SQL，不如显式拆解：
- 将“2023-07 至 2024-06”拆为两个子查询：
SELECT ... WHERE stat_date >= '2023-07-01' AND stat_date = '2024-01-01' AND stat_date - 每个子查询都能精准命中分区+索引，执行计划确定，且支持并行执行（尤其在ClickHouse、Doris等引擎中效果明显）
- 注意
UNION ALL不排序不去重，如需全局ORDER BY，只在外层加一次
统计口径提前固化，减少运行时计算
报表里大量CASE WHEN、DATE_FORMAT、自定义函数，不仅拖慢速度，还阻碍索引下推和分区裁剪。
- 把业务规则转成预计算字段：如“财年月份”（7月→FY2401）、“销售阶段分类”（lead/opportunity/closed），写入宽表并建索引
- 用视图封装逻辑，但底层表必须有对应索引；不要在视图里写
JOIN + GROUP BY后再被外层再聚合 - 日期类字段统一存DATE类型，别存VARCHAR，避免每次查询都
STR_TO_DATE()
