MySQL 8.0 默认启用 Hash Join，但仅当满足等值连接、小表可内存缓存、无可用索引三个硬性前提时才实际触发；需用 EXPLAIN FORMAT=TREE 确认，大表关联易因内存不足导致磁盘溢出而性能骤降。
MySQL 8.0 默认启用 Hash Join，但只有满足等值连接、小表可内存缓存、无非等值条件时才会实际触发——不手动干预也能用上，但盲目依赖会踩坑。
Hash Join 触发的三个硬性前提
MySQL 优化器不会“随便”选 Hash Join，它只在明确符合以下全部条件时才启用：
- 连接条件必须是纯等值（
=），不能含、BETWEEN、LIKE或函数包装（如DATE(created_at) = '2023-01-01'） - 参与连接的两个表中，至少有一个能被完整加载进内存（由
join_buffer_size和表估算行数共同决定） - 连接字段上没有可用索引（或优化器判断走索引不如哈希快），否则可能退回到
Index Nested Loop Join
例如：SELECT * FROM orders o JOIN users u ON o.user_id = u.id 可能触发；而 ON o.user_id = u.id AND o.status IN ('paid', 'shipped') 中的 IN 条件会迫使非等值部分后置过滤，Hash Join 仍可用，但若写成 ON o.user_id > u.id，则直接禁用。
如何确认当前查询是否用了 Hash Join
不能靠 EXPLAIN 默认输出，必须用树形执行计划：
- 执行
EXPLAIN FORMAT=TREE SELECT ...，输出中出现Inner hash join或Left hash join字样即为命中 - 若看到
Block nested loop或Nested loop，说明没走 Hash Join，可能是条件不满足，也可能是小表太大导致内存不足被迫降级 - 用
EXPLAIN ANALYZE可进一步看到真实构建哈希表耗时与探测耗时，比FORMAT=TREE更准
示例输出片段：-> Inner hash join (u.id = o.user_id) (cost=1.05 rows=1) —— 这里的 u.id = o.user_id 就是哈希键，括号外的 cost 和 rows 是优化器估算值。
大表关联时 Hash Join 的性能陷阱
Hash Join 不是银弹，尤其在 12 表关联场景下容易误判：
- 多层
JOIN中，MySQL 每次只对**相邻两表**做一次 Hash Join，不会全局建一个大哈希表；所以t1 JOIN t2 JOIN t3实际是先t1+t2哈希，再把结果集当新“小表”去哈希t3，中间结果膨胀会迅速吃光内存 - 如果某张表估算行数远超
join_buffer_size（默认 256KB），MySQL 会自动拆分哈希表到磁盘，引发大量随机 I/O，比内存版慢一个数量级 -
LEFT JOIN无法完全哈希化：左表必须全保留，右表匹配失败也要补NULL，所以 MySQL 对LEFT JOIN的哈希实现更保守，常搭配Filter节点，性能不如INNER JOIN稳定
典型症状：执行时间忽高忽低、EXPLAIN FORMAT=TREE 显示 Hash 但实际慢，大概率是哈希表溢出到了磁盘。
可控的优化动作：不是调参，而是改写
与其反复调 join_buffer_size，不如从 SQL 结构入手让 Hash Join 更可靠：
- 把真正需要的字段提前
SELECT，避免SELECT *把大字段（如TEXT、BLOB）拖进哈希过程，增大内存压力 - 对超大事实表（如订单明细），先用
WHERE严格过滤（如WHERE order_date >= '2025-01-01'），再参与 JOIN，缩小驱动表体积 - 混合
INNER JOIN和LEFT JOIN时，把INNER JOIN放前面，确保早期连接就压住结果集规模，避免LEFT JOIN在后期放大中间数据 - 若发现某张表始终无法进内存（比如用户表有千万级且无业务过滤），考虑用物化临时表 + 主键分批处理，绕过单次哈希瓶颈
最常被忽略的一点：Hash Join 效果高度依赖优化器对表行数的估算。如果 ANALYZE TABLE 长期未执行，或统计信息陈旧，优化器可能误判“小表”，导致本该哈希的没哈希，本不该哈希的强行哈希再溢出——定期 ANALYZE TABLE 比调 join_buffer_size 实在得多。
