跨年查询慢主因是跨分区导致扫描大、索引失效、裁剪失败；应确保where中显式、直接使用分区键（如dt），避免函数操作，使查询落在单个或连续小范围分区。
跨年统计慢，往往不是SQL写得不好，而是数据跨了多个分区，导致扫描范围大、索引失效、分区裁剪失败。核心优化方向是让查询尽量落在单个分区或连续小范围分区内，同时确保分区键被正确用于过滤和连接。
确认分区键是否参与了WHERE条件
很多跨年查询写成 WHERE create_time BETWEEN '2023-01-01' AND '2024-12-31'，看似合理，但如果分区字段是 dt STRING（如 '20230101'）或 year_month STRING（如 '2023-12'），而WHERE里用的是其他时间字段，分区根本不会被裁剪。
- 检查表的分区字段名（如 dt、ym、year_id、month_id），确保WHERE中直接、显式地使用它
- 避免在分区字段上做函数转换，比如 WHERE substr(dt,1,4) = '2024' 会禁用分区裁剪；应改写为 dt >= '20240101' AND dt
- 如果业务时间字段（如 order_time）和分区字段（dt）不一致，优先按 dt 过滤，再用 order_time 做二次筛选
避免JOIN引发全分区扫描
两张按天分区的大表A和B做JOIN，若ON条件未包含分区字段，或只有一方有分区过滤，另一方极易触发跨年全量扫描。
- JOIN时，确保双方都带上对齐的分区条件，例如：
A JOIN B ON A.order_id = B.order_id
WHERE A.dt BETWEEN '20240101' AND '20241231'
AND B.dt BETWEEN '20240101' AND '20241231' - 若B表是维表且无对应dt分区，考虑提前用
DISTRIBUTE BY或BROADCAST提示（如Spark SQL的/*+ BROADCAST(b) */）避免shuffle扫描 - 临时表/中间结果务必按dt重分区并持久化，防止下游反复读取跨年原始分区
用时间维度表替代跨年范围扫描
对固定周期（如近3年年度汇总）场景，预计算比每次动态扫描更高效。
- 建一张年粒度汇总表，按 year INT 分区，每日增量合并当日明细到对应年分区
- 跨年报表直接查这张年表，WHERE year IN (2022,2023,2024)，秒级响应
- 搭配物化视图（如StarRocks、Doris的MV）或定时INSERT OVERWRITE，兼顾实时性与性能
检查执行计划，定位真实扫描分区数
别猜，要看实际执行时读了哪些分区。不同引擎命令不同，但目标一致：验证是否真的“跨了不该跨的区”。
- Hive/Spark SQL：加 EXPLAIN EXTENDED，搜
PartitionFilter或PartitionCount，看是否列出了几百个dt值 - Doris：用 EXPLAIN SELECT，关注
partitions=xxx行，数字应接近实际年份跨度（如3年≈365×3=1095？错！应是3个分区，若按年分区） - ClickHouse：EXPLAIN PIPELINE + SETTINGS send_logs_level = 'debug'，查
Used partitions
