hash join在无索引等值连接中性能更优，因其通过内存哈希表构建与一次顺序扫描将时间复杂度从o(m×n)降至o(m+n)，但需满足小表可入内存、优化器正确选择驱动表且无隐式转换等前提条件。
Hash Join 在没有索引时快，不是因为它“绕过了索引缺失的缺陷”，而是它根本不需要索引——它用一次内存哈希表构建 + 一次顺序扫描，把 O(M×N) 的暴力匹配降成了接近 O(M+N) 的线性操作。
EXPLAIN FORMAT=TREE 看不到 hash join？先确认命令对不对
- 默认
EXPLAIN（即FORMAT=TRADITIONAL）完全不显示hash join，哪怕实际已启用，Extra 字段只会写Using join buffer (Block Nested Loop)或空，极易误判。 - 必须用：
EXPLAIN FORMAT=TREE或EXPLAIN ANALYZE，输出里出现Inner hash join和Hash子节点才算实锤。 - 示例：
EXPLAIN FORMAT=TREE SELECT * FROM t1 JOIN t2 ON t1.id = t2.t1_id\G
→ 输出含-> Inner hash join (t2.t1_id = t1.id)才是真用了。
驱动表选错或有索引，hash join 会被悄悄跳过
MySQL 优化器不会因为“你写了 JOIN”就无脑选 hash join，它优先保稳定、控内存：
- 如果
t2.t1_id上有索引，即使t1很小，优化器大概率走Index Nested-Loop Join（INLJ），因为点查比建哈希表更可控、内存开销更低。 - 如果
t1实际行数远大于预估（统计信息陈旧），优化器可能误判谁小，选错驱动表，导致哈希表建不出来或溢出。 -
LEFT JOIN/RIGHT JOIN中，被驱动侧若需保留 NULL 行，hash join可能被抑制（8.0.20+ 已支持部分外连接场景，但非默认）。
验证方法：
- 执行
SHOW WARNINGS查是否有隐式类型转换或索引失效提示； - 用
ANALYZE TABLE t1, t2更新统计信息； - 临时禁用索引测试：
SELECT * FROM t1 JOIN t2 IGNORE INDEX (idx_t1_id) ON t1.id = t2.t1_id，再看FORMAT=TREE。
join_buffer_size 设太大或太小都会拖慢 hash join
哈希表默认在内存中构建，大小受每个连接独享的 join_buffer_size 控制，但它不是越大越好：
- 设太小（如默认 256K）：哈希表装不下驱动表，触发分块处理，甚至落盘 → 多轮
Probe+ 文件读写，Handler_write暴增，延迟陡升。 - 设太大（如 >64M）：可能挤占
innodb_buffer_pool_size，反致主查询缓存命中率暴跌；极端时触发 OS 内存分配失败（ENOMEM）。 - 推荐值：根据驱动表预估体积设为 4M–32M，例如驱动表约 10 万行 × 100 字节 ≈ 10MB，可设
join_buffer_size = 16M。
检查当前值：
SELECT @@join_buffer_size;动态调整（仅当前会话）：
SET SESSION join_buffer_size = 16777216;
hash join 的快，依赖的是“小表可进内存 + 无索引 + 等值连接”这个三角条件。一旦驱动表实际体积超出 join_buffer_size，或优化器因统计不准/隐式转换误判了数据分布，它就会退化——这时看 EXPLAIN ANALYZE 里的 disk-swap 或 buffer_used 值，比看执行计划更真实。
