EXPLAIN FORMAT=TREE是唯一能直观显示Hash Join构建表、探测表及连接键的命令，其树状结构中“Inner hash join (t2.c1 = t1.c1)”明确标识探测表字段在左、构建表字段在右，带Hash标签的子节点为构建表扫描，另一支为探测表扫描；EXPLAIN ANALYZE则补充实际扫描行数、build/probe耗时及disk overflow标记，可验证内存是否充足、驱动表选择是否合理。
EXPLAIN FORMAT=TREE 是唯一能直观看到 Hash Join 匹配过程的命令，其他格式（如 EXPLAIN 默认或 EXPLAIN FORMAT=TRADITIONAL）只会显示 Using join buffer (hash join) 这类模糊提示，无法反映构建表、探测表、哈希键等关键结构。
怎么看懂 EXPLAIN FORMAT=TREE 输出里的 Hash Join 节点
输出是嵌套树状结构，每层缩进代表执行层级。Hash Join 节点本身会明确写出 Inner hash join 或 Left hash join，并标注连接键，例如：Inner hash join (t2.c1 = t1.c1)。
- 等号左边的字段（
t2.c1）是探测表（被驱动表）的连接列 - 等号右边的字段（
t1.c1）是构建表（驱动表）的连接列 - 其子节点中带
Hash标签的那一支，就是构建阶段扫描的表（如Table scan on t1） - 另一支不带
Hash的，就是探测阶段扫描的表（如Table scan on t2） - 如果出现多层
hash join嵌套（比如三表 JOIN），说明 MySQL 拆成了多个两表 Hash Join 步骤，从右向左或按代价估算顺序执行
EXPLAIN ANALYZE 能补全哪些关键信息？
EXPLAIN ANALYZE 会在实际执行 SQL 后返回运行时统计，比 FORMAT=TREE 多出三类关键数据：
- 每张表实际扫描行数（
rows字段），可验证优化器是否真选了小表做构建表 - 哈希表构建耗时（
build time）和探测耗时（probe time），差距大说明内存不足触发了磁盘溢出 - 是否发生
disk overflow—— 若出现该字样，说明构建表超出join_buffer_size，已分块写入磁盘，性能必然下降
为什么有时候明明没索引，却没走 Hash Join？
常见原因不是语法错，而是优化器“绕过”了它：
- JOIN 条件里混入了
OR、LIKE、函数表达式（如UPPER(t1.name) = t2.name），哪怕只有一处，整个 ON 子句就不再满足纯等值条件 - 存在可用的单表索引（例如
WHERE t1.id = ?有主键索引），优化器倾向用Index Nested-Loop Join，即使连接列本身无索引 - 表统计信息陈旧，
ANALYZE TABLE没执行过，导致优化器误判构建表大小，选错驱动方 - MySQL 8.0.18–8.0.19 允许用
SET optimizer_switch='hash_join=off'关闭，但 8.0.20+ 该开关已失效，无需检查
如何稳定触发并验证 Hash Join 生效？
最可靠的方式不是猜配置，而是控制输入结构：
- 用派生表强制“断开”原始表与索引的关联：
SELECT * FROM (SELECT * FROM t1 WHERE ... ) AS a JOIN (SELECT * FROM t2 WHERE ... ) AS b ON a.c1 = b.c1 - 确保 ON 中只有简单等号，且两边字段均为基础列（非表达式、非 NULL 安全比较
） - 执行前先
ANALYZE TABLE t1, t2更新统计信息 - 必须用
EXPLAIN FORMAT=TREE看树形结构，再用EXPLAIN ANALYZE看真实耗时与溢出标记
真正容易被忽略的是：Hash Join 的性能优势高度依赖构建表能否全量驻留内存。一旦触发磁盘溢出，I/O 开销可能反超 Nested-Loop —— 所以 join_buffer_size 不是越大越好，而是要略大于预估的构建表字节大小（注意是字节数，不是行数）。
