Hash Join仅在无索引等值连接时启用：需INNER/LEFT JOIN、全=条件、被驱动表无可用索引；生效需EXPLAIN FORMAT=TREE确认Inner hash join节点；性能依赖驱动表大小与join_buffer_size匹配，超限将降级并写磁盘。
Hash Join只在无索引等值连接时自动启用
MySQL 8.0不会因为你升级了就默认“用上”Hash Join——它只在满足三个硬性条件时才可能被优化器选中：INNER JOIN或LEFT JOIN（右表为被驱动表）、连接条件全是=、且被驱动表的关联字段**没有可用索引**。一旦被驱动表上有索引，优化器大概率走Index Nested-Loop Join，哪怕Hash Join实际更快，它也优先选更稳的。你看到EXPLAIN里出现Using join buffer (hash join)，只是表面信号；真正确认是否生效，必须用EXPLAIN FORMAT=TREE，找输出里的Inner hash join节点。
驱动表大小和join_buffer_size决定Hash Join是否真快
Hash Join快的前提是构建阶段能塞进内存。如果驱动表太大，超出join_buffer_size（注意：MySQL 8.0.20+已弃用block_nested_loop开关，但join_buffer_size仍控制Hash Join内存上限），MySQL会分块处理，甚至写磁盘临时文件，性能断崖下跌。实操建议：
- 用
EXPLAIN ANALYZE看执行细节，重点关注buffer_used是否接近join_buffer_size，以及是否有disk-swap字样 - 临时调大
join_buffer_size（如设为4M）做对比测试，但别在线上长期设过高，避免挤占其他查询内存 - 如果驱动表本身很大，考虑用
WHERE先过滤、或加覆盖索引减少驱动表扫描行数，比硬调缓冲区更可靠
IGNORE INDEX能强制触发Hash Join，但仅限诊断
当你怀疑有索引反而拖慢了关联（比如被驱动表索引区分度极低，回表开销远超全表扫描），可以用IGNORE INDEX临时禁用索引，再用EXPLAIN FORMAT=TREE观察是否切到hash join。例如：
EXPLAIN FORMAT=TREE SELECT * FROM orders o JOIN products p ON o.product_id = p.id IGNORE INDEX (PRIMARY);
但要注意：IGNORE INDEX是调试手段，不是优化方案。线上直接使用会导致执行计划不稳定，且一旦索引重建或统计信息更新，行为可能突变。真实优化应聚焦于索引设计合理性，而非绕过索引。
多表JOIN中Hash Join只作用于单对表，顺序很关键
MySQL不支持跨三张以上表的全局Hash Join。它每次只对一对表尝试Hash Join，而哪一对先连，取决于优化器选出的驱动表顺序。如果你写的是A JOIN B JOIN C，优化器可能先算A JOIN B（用Hash Join），再拿结果集去连C（可能又退化成NLJ）。这意味着：中间结果集大小直接影响后续连接效率。最容易被忽略的一点是——即使第一对用了Hash Join，如果A JOIN B产出几百万行，再连C时，C很可能因数据量过大而无法进内存哈希，最终整条链路性能卡在第二段。所以，别只盯着单个hash join节点，要通读整个EXPLAIN FORMAT=TREE输出，看每层连接的预估行数和算法类型。
