Hash JOIN性能优化关键在于单节点执行，需确保JOIN字段均为分片键且分片函数一致；否则将退化为广播或重分布。
分布式环境下，Hash JOIN 很容易变成性能黑洞——不是它本身慢，而是它被迫在跨节点场景下反复搬运数据。真正有效的优化，从来不是调参数，而是让 Hash JOIN 尽可能在单节点内完成。
确保JOIN字段是分片键且函数一致
这是最硬的前置条件。如果 orders.user_id 是分片键，但 users.id 不是，或两者分片函数不同（比如一个用 hash(user_id)，另一个用 mod(user_id, 12)），那任何 Hash JOIN 都会退化为广播或重分布。
- 用
SHOW CREATE TABLE或对应系统命令确认两表的分片定义是否完全对齐 - 避免用非分片字段做
ON条件，例如orders.email = users.email—— 即使都有索引，也大概率触发全表广播 - 某些系统（如 TiDB）支持
/*+ TIDB_BROADCAST(t2) */，但只在t2真正小（
启用并行Hash JOIN前先确认扫描收益
tdsql_enable_parallel_hash_join 开关打开后，并不等于所有 Hash JOIN 都变快。它只对两侧都能高效并行扫描的场景有效，比如大事实表 + 大维度表，且都带范围过滤。
- 检查执行计划中是否出现
shared hash和with range parallel scan；若只有table scan没有parallel标识，说明底层存储不支持或数据太小，强行并行反而增加调度开销 - 小表（Hash JOIN 通常比并行更快，因构建哈希表成本低，且无线程同步开销
- 若需强制验证，并行度建议从
/*+ parallel(t1, 2) parallel(t2, 2) */起步，避免直接设为 CPU 核数导致资源争抢
警惕LEFT JOIN右表无索引引发的放大扫描
在分布式库中，LEFT JOIN 的右表若没在 ON 字段建索引，不是“慢一点”，而是“每个分片都扫一遍右表”。比如 12 个分片的集群，右表被扫描 12 次。
- 必须确保右表的
JOIN字段有索引，且类型与左表严格一致（BIGINT对INT会隐式转换，索引失效） - 避免在右表
ON条件中加函数，如ON u.id = CAST(o.user_id AS SIGNED)，这会阻止下推，导致远程全表扫描 - 用
EXPLAIN FORMAT = 'VERBOSE'（TiDB）或EXPLAIN (DISTINCT ON)（CockroachDB）确认右表是否出现在TableReader下方；若在顶层Selection，说明过滤没下推
用物化视图固化高频JOIN路径
当某类 JOIN 几乎每次查询都出现（如 orders 关联 products 和 users），实时计算就是浪费。与其每次重建哈希表，不如把关联结果存下来。
- 在 StarRocks 或 Doris 中，直接建
MATERIALIZED VIEW；TiDB 暂不支持自动刷新，可用定时任务 +REPLACE INTO ... SELECT模拟 - 注意宽表陷阱：不要把
products.description这类 500 字符字段直接塞进物化视图，除非真需要；优先只存 ID、状态、分类等高区分度字段 - 刷新频率取决于业务容忍度，订单类数据可设为每 5 分钟，用户画像类可设为每小时；避免秒级刷新，元数据压力会飙升
最容易被忽略的点是：分布式 Hash JOIN 的瓶颈从来不在哈希计算本身，而在数据是否真的“本地”。只要看到执行计划里有 Exchange、RemoteScan 或 Gather，第一反应不该是调并行度，而是回去检查分片键对齐和索引覆盖——这是唯一能砍掉 90% 网络耗时的操作。
