hash join虽不依赖索引匹配，但索引对驱动表过滤、连接字段预处理及内存控制至关重要；缺失索引会导致哈希表膨胀、内存溢出或退化为bnl/nlj。
Hash Join不走索引，但索引仍关键
Hash Join本身不依赖索引完成匹配——它靠哈希表探测，不是B+树查找。但这不意味着索引可以扔掉。真实场景中，驱动表和被驱动表的过滤、连接字段预处理、内存占用控制，都直接受索引影响。
比如：WHERE条件若无法下推到驱动表扫描前，就会让本该 10 万行的驱动表变成 1000 万行再建哈希表，内存溢出风险陡增；而一个覆盖 WHERE + JOIN 字段的联合索引，能直接让驱动表只读取有效行。
- 驱动表上的
WHERE条件必须有索引，否则全表扫描后才过滤，哈希表体积失控 - 被驱动表若也有索引，虽然 Hash Join 不用它做连接，但
ORDER BY或LIMIT可能触发索引排序，避免临时表 - 连接字段类型不一致（如
VARCHAR对CHAR）会导致隐式转换，使索引失效，进而让优化器放弃 Hash Join 回退到 BNL
什么时候MySQL 8.0会跳过Hash Join选NLJ或BNL？
优化器不是无脑选 Hash Join。它会综合评估驱动表大小、内存预算、连接字段选择性、是否启用 hash_join 开关等。常见放弃 Hash Join 的信号包括：
-
EXPLAIN中出现Using join buffer (Block Nested Loop)：说明join_buffer_size不足或驱动表太大，降级为 BNL - 执行计划显示
Using where; Using index在被驱动表上：优化器判断 NLJ + 索引查找比建哈希表更快（尤其当被驱动表极小且索引高效时） - 连接条件含函数或表达式，如
ON UPPER(t1.code) = t2.code：哈希无法对运行时计算值建表，强制退回到 NLJ - 全局变量
optimizer_switch中hash_join=off被手动关闭（默认是 on）
如何确认当前查询真正在用Hash Join？
不能只看 EXPLAIN FORMAT=TREE 里有没有 “Hash join” 字样——那是逻辑计划；得看实际执行路径。最可靠的方法是查 performance_schema.events_statements_history_long 或用 SYS.schema_table_statistics_with_buffer 辅助验证。
更直接的操作是开启 optimizer trace：
SET optimizer_trace="enabled=on,one_line=off"; SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.status = 'active'; SELECT * FROM information_schema.OPTIMIZER_TRACE\G
在输出中搜索 "chosen_join_algorithm": "hash_join" 和 "hash_join_cost" 字段。若看到 "chosen_join_algorithm": "nested_loop" 却加了 HASH_JOIN hint，说明强制失败，通常是因为不满足等值连接或内存限制。
Hash Join + 索引的实操组合策略
真正提升性能的不是“用了 Hash Join”，而是“用对了驱动表 + 压缩了哈希表 + 控制了内存”。索引在这里是隐形杠杆：
- 驱动表优先选过滤性强的小表，并确保
WHERE条件列有索引——例如orders WHERE created_at > '2026-08-01'配合(created_at, user_id)联合索引，可把驱动行数从千万压到几万 - 被驱动表的连接字段必须是等值、非空、类型一致；若字段允许 NULL，哈希表会额外处理 NULL 分桶，拖慢探测速度
- 调大
join_buffer_size（注意是会话级，非全局）可减少磁盘分桶次数，但超过sort_buffer_size或系统物理内存 20% 后收益急剧下降 - 对超大被驱动表，哪怕不用索引做连接，也建议在连接字段上建索引——因为 Hash Join 扫描被驱动表时仍需顺序 I/O，有索引可提升预读效率（尤其 SSD 场景）
最容易被忽略的一点：Hash Join 对 NULL 值的处理是特殊分支，不是简单哈希碰撞失败。只要连接字段存在大量 NULL，即使其他条件都完美，性能也会明显劣化——这不是 bug，是设计如此。
