分区字段必须作为join条件的一部分，否则无法触发分区裁剪；join key类型和null值需严格一致；小表广播需手动控制阈值并确认大小；谓词必须字面量且不包裹函数才能下推。
分区字段必须作为Join条件的一部分
如果日志表按 dt（日期）或 hour 分区，但 JOIN 语句里没带上这些字段的等值条件，查询会扫描所有分区——哪怕你只查昨天的数据。Hive、Spark SQL、Trino 都不会自动裁剪。
常见错误写法：SELECT * FROM logs l JOIN dim_user u ON l.user_id = u.id WHERE l.dt = '2024-06-15'
这里 WHERE 在逻辑上过滤了数据，但优化器无法保证 dim_user 表不触发广播或 logs 不全表扫描（尤其当 dim_user 没分区时）。
- 正确做法：把分区字段放进
ON子句，且两边对齐，例如ON l.user_id = u.id AND l.dt = u.dt（前提是dim_user也按dt分区） - 若维表不分区，至少在
JOIN后立刻加WHERE l.dt = '2024-06-15'，并确认执行计划中Filter出现在TableScan下方（即谓词下推生效） - 用
EXPLAIN或EXPLAIN FORMATTED检查实际读取的分区数，避免看到PartitionFilters: [isnotnull(dt), ...]却没具体值
小表 Broadcast Join 要手动控制大小阈值
默认广播阈值（如 Spark 的 spark.sql.autoBroadcastJoinThreshold）常设为 10MB，但日志场景下维表可能有 50MB（比如带用户画像宽表），此时系统仍走 Shuffle Join，性能断崖式下降。
实操建议：
- 先用
SELECT COUNT(*) FROM dim_user和ANALYZE TABLE dim_user COMPUTE STATISTICS（Hive）或ANALYZE dim_user（Trino）确认真实大小 - 显式开启广播：Spark 中加
/*+ BROADCAST(dim_user) */；Trino 用/*+ JOIN_ORDER(dim_user, logs) */配合小表优先 - 避免广播失败：若维表压缩后仍超内存，考虑先
FILTER再广播，例如SELECT /*+ BROADCAST(u) */ * FROM logs l JOIN (SELECT * FROM dim_user WHERE is_active = 1) u ON ...
Join Key 类型和 NULL 值必须严格一致
日志表的 user_id 是 STRING，维表却是 BIGINT？或者一边是空字符串 ''，一边是 NULL？这类隐式转换或语义不匹配会让 Join 变成 Cartesian Product 级别的灾难——数据倾斜、OOM、任务卡死。
排查与修复：
- 检查 DDL：用
DESCRIBE FORMATTED logs和DESCRIBE FORMATTED dim_user对比字段类型，特别注意user_id、event_type等高频 Join 字段 - 统计 NULL 和空值比例：
SELECT COUNT(*) FILTER (WHERE user_id IS NULL OR user_id = ''), COUNT(*) FROM logs - 强制统一类型：在 Join 前显式转换，如
CAST(l.user_id AS BIGINT)，但要确保无非法字符；更安全的是用NULLIF(TRIM(l.user_id), '')清洗后再 Join
分区裁剪失效时，优先检查谓词是否可下推
写了 WHERE dt BETWEEN '2024-06-15' AND '2024-06-16' 却仍扫全量分区？大概率是用了不可下推的表达式。
典型陷阱：
-
WHERE SUBSTR(dt, 1, 8) = '20240615'→ 分区字段被函数包裹，裁剪失效 -
WHERE dt >= date_sub(current_date(), 1)→ 动态函数在编译期无法确定值，部分引擎（如旧版 Hive）不支持 -
WHERE dt IN (SELECT max_dt FROM last_7_days)→ 子查询结果未内联，裁剪失败
解决方式：全部改用字面量或预计算变量。Spark SQL 可用 SET dt='2024-06-15'; SELECT ... WHERE dt = ${hiveconf:dt}；Hive 脚本中用 hive -d dt=2024-06-15 -f join.sql。
分区字段的值必须原样出现在 WHERE 或 ON 中，不加工、不拼接、不嵌套函数——这是裁剪生效最硬的边界。
