非关联子查询易触发Hash Join，因其逻辑等价于无依赖的等值连接，且子查询结果小、可哈希建表，主表大而无索引，使Nested Loop反复全扫、Merge Join缺乏排序优势，Hash Join成为最优选择。
Hash Join 在执行计划中常用于处理非关联的大表子查询，根本原因不是“它天生适合子查询”，而是优化器发现：**该子查询等价于一个无驱动依赖的等值连接，且内表（子查询结果）足够小、可哈希建表，外表（主表）又大且无索引可用**。
这类场景下，Nested Loop Join 会退化成对子查询结果的反复全量执行（尤其当子查询不能物化或未被缓存时），而 Merge Join 又要求双方已排序——所以 Hash Join 成为唯一兼顾吞吐与可控内存开销的选择。
为什么非关联子查询容易触发 Hash Join？
非关联子查询（如 WHERE x IN (SELECT y FROM t2) 或 EXISTS (SELECT 1 FROM t2 WHERE t2.a = t1.b)）在逻辑上不依赖外层行，但物理执行时仍需建立匹配关系。优化器会将其重写为半连接（semi-join）或反连接（anti-join），并按以下规则决策：
- 若子查询返回结果集较小（比如
SELECT DISTINCT category_id FROM dim_category WHERE active = 1返回几百行），优化器倾向选它作build input - 若主表连接字段无索引，或存在隐式转换（如
t1.status_code = t2.code中一边是INT一边是VARCHAR），Nested Loop的索引查找失效，只能全表扫描内表——此时每行主表都触发一次全扫，成本爆炸 - 子查询本身不含
ORDER BY或聚合，无法利用Merge Join的有序性优势
不同数据库对子查询 Hash Join 的触发差异
各数据库对子查询是否走 Hash Join 的判断逻辑不同，关键参数和行为如下：
-
SQL Server：默认启用
HASH_SJ（Hash Semi-Join）提示；若子查询被标记为IsCorrelated = false且行数预估 Hash Match -
PostgreSQL：对
IN子查询，若子查询结果集小于work_mem的 1/4，且主表连接列无索引，会生成Hash Semi Join节点 -
MySQL 8.0+：仅在
EXISTS/IN子查询被物化（Materialized）后才可能用Hash Join；需开启optimizer_switch='materialization=on,hash_join=on' -
Oracle：使用
HASH_AJ（Hash Anti-Join）或HASH_SJ提示强制；CBO 在子查询 cardinality 低且 join key 无函数包裹时自动选择
容易踩的坑：你以为是 Hash Join，其实没生效
执行计划里出现 Hash Join 字样，不代表真走哈希路径。常见假阳性现象包括：
- 只看到
JOIN关键字或USING，但EXPLAIN ANALYZE输出里没有Hash Cond（PostgreSQL）或PhysicalOp="Hash Match"（SQL Server） - 哈希表实际溢出到磁盘：
Buffers: temp read/write值很大（PostgreSQL），或 SQL Server 执行计划中TempDB消耗远超预期 - 子查询含
GROUP BY或LIMIT，导致优化器放弃物化，改用Nested Loop逐行探测 - 连接字段用了函数，如
UPPER(t1.code) = t2.code，即使子查询非关联，Hash Join也无法构建有效哈希键（因函数结果不可预先计算）
Hash Join 的，从来不是“子查询是否关联”，而是“构建侧能否放进内存 + 探测侧是否值得避免重复扫描”。很多线上慢查卡在几十秒，翻执行计划才发现 Hash Join 已悄悄退化成多轮临时文件读写——这时调大 work_mem 或 join_buffer_size，比加索引更直接有效。 
