有用，但仅当join条件恰好使用分区键时才生效；分区裁剪依赖谓词下推，需where或on中等值匹配分区列；分区过多反致元数据压力和小文件问题。
分区表对 JOIN 性能到底有没有用？
有用，但只在 JOIN 条件里恰好用了分区键时才生效。比如 orders 按 dt 分区，users 按 region 分区，那 JOIN ... ON o.dt = u.dt 才可能裁剪分区；若写成 ON o.user_id = u.id，分区完全不参与过滤，引擎照样扫全量。
- 分区不是索引，它不加速字段查找，只减少扫描的数据量
- Hive/Trino/Spark SQL 中，分区裁剪依赖谓词下推，
WHERE或JOIN ON里的等值条件必须字面匹配分区列名和类型 - 分区过多（如按小时分）会导致元数据压力大，小文件问题更严重，反而拖慢 JOIN
哪些字段该建索引？别在大数据里乱建
传统数据库的 B-Tree 索引在 Hive、Spark、Trino 这类计算引擎上基本无效——它们不支持索引驱动的随机读。唯一例外是某些 OLAP 引擎（如 Doris、StarRocks）的物化索引或前缀索引，但仅对点查或前缀匹配有效，对 JOIN 本身无直接加速作用。
- 别在 Hive 表上执行
CREATE INDEX：已废弃，且不被主流执行引擎（Spark SQL、Trino）使用 - StarRocks 的
BITMAP或BLOOMFILTER索引可加速JOIN中的IN或等值过滤，但前提是该字段是JOIN条件之一，且建在事实表的关联列上 - 真正起效的是“索引覆盖”：把
JOIN和SELECT需要的所有字段，都放在同一张宽表或物化视图里，避免多表实时关联
如何让 JOIN 走 Map-side？关键看大小表和分布
Map-side JOIN（也叫 Broadcast JOIN）能把小表广播到每个 task，彻底规避 Shuffle，是提速最直接的方式。但它有硬约束：小表必须足够小，且不能动态膨胀。
- Spark 中默认阈值是
spark.sql.autoBroadcastJoinThreshold=10MB，超了就退化为 Sort-Merge JOIN；可调高，但内存溢出风险同步上升 - 小表不能含运行时不可知大小的数据源，比如未加
LIMIT的子查询、或依赖参数的动态过滤结果 - Trino 用
join-distribution-type=automatic自动判断，但若小表来自VALUES或UNNEST，可显式加/*+ BROADCAST */提示 - 注意数据倾斜：即使广播了，若大表某 key 出现百万次，单个 task 仍会 OOM
为什么改了分区和广播还是慢？检查 JOIN 顺序和 NULL 处理
JOIN 顺序直接影响中间结果集大小，而 NULL 值会让很多优化失效——比如分区裁剪、Broadcast 判定、甚至统计信息估算都会失准。
- 把过滤最狠的表放左边（SQL 中第一个
FROM），尤其当它带强WHERE条件时；否则先 JOIN 出巨量中间行，再过滤，浪费资源 -
JOIN ON a.id = b.id若任一端id含大量 NULL，Hive/Spark 会把所有 NULL 归到同一个 reducer，引发严重倾斜 - 提前用
WHERE id IS NOT NULL或FILTER掉 NULL，比在 JOIN 后WHERE更早生效 - 统计信息过期（
ANALYZE TABLE没跑）会导致执行计划误判大小表，强制广播失败或选错 JOIN 算法
