SQL跨周期对比慢的核心原因是未有效利用时间分区。需确认表按时间字段合理分区，查询时显式过滤分区键，聚合下沉至单分区后再合并，通过EXPLAIN验证分区裁剪是否生效。
SQL报表做跨周期对比慢，核心问题往往出在时间分区统计没用好。直接对全量时间范围扫描，尤其是跨月、跨年对比时，数据库要读取大量无关分区，IO和计算都吃紧。
确认表是否已按时间字段合理分区
先查表结构和分区信息，确保时间字段（如 dt、event_time）是分区键，且分区粒度匹配业务需求（比如按天分区适合日环比，按月分区适合年同比）。
- MySQL：用 SHOW CREATE TABLE 看 PARTITION BY 子句
- Hive/Spark SQL：用 DESCRIBE FORMATTED table_name 查分区字段和方式
- ClickHouse：查 system.parts 表，确认 partition 字段是否有效切分
写SQL时显式过滤分区字段，避免全表扫描
跨周期对比不能只靠 WHERE 中的日期条件（如 WHERE event_time BETWEEN '2024-01-01' AND '2024-03-31'），必须同时带上分区字段的等值或 IN 条件。
- 正确写法（Hive示例）：WHERE dt IN ('2024-01-01', '2024-02-01', '2024-03-01') AND event_time >= '2024-01-01'
- 错误写法：WHERE event_time >= '2024-01-01' AND event_time < '2024-04-01'（可能跳过分区裁剪）
- 注意：分区字段类型要和过滤值一致，字符串分区别传时间戳，否则分区失效
聚合逻辑下沉到单分区，再合并对比结果
别在一个大查询里 JOIN 多个周期的全量明细。应先按分区分别聚合（如每天汇总订单数、GMV），再把聚合结果集 UNION 或 JOIN 对比。
- 例如：先算出 SELECT dt, COUNT(*) AS cnt FROM t WHERE dt='2024-03-01' GROUP BY dt
- 再和 dt='2024-02-01' 的聚合结果 JOIN，而不是拉两份明细再关联
- 这样能大幅减少中间数据量，也利于分区并行执行
检查执行计划，验证分区裁剪是否生效
运行 EXPLAIN（或 EXPLAIN FORMAT=JSON）看实际读取的分区列表。如果显示 partitions: all 或读了几十个无关分区，说明过滤条件没触发裁剪。
- 常见陷阱：用了函数包装分区字段，如 WHERE TO_DATE(dt) = '2024-03-01' → 改成 WHERE dt = '2024-03-01'
- 分区字段参与 JOIN 或子查询时，也可能导致裁剪失效，需拆解或加冗余过滤
- 部分引擎（如旧版Hive）对 IN 子句大小有限制，超限会退化为全扫，可改用多个 UNION ALL
不复杂但容易忽略：分区不是建了就自动加速，关键在SQL怎么写、执行计划怎么看、聚合时机怎么选。
