哈希连接将时间复杂度从o(m×n)降至o(m+n)，核心是仅扫描被驱动表一次，避免bnl的多次全表扫描；需用explain format=tree验证是否启用，有索引时优化器优先选择更稳定、内存开销更低的index nested-loop join。
哈希连接把 O(M×N) 降为 O(M+N)，核心是避免重复扫描
BNL（Block Nested Loop）在无索引时，被驱动表要被反复全表扫描几十次；而 Hash Join 只需扫描一次。比如驱动表剩 5000 行、join_buffer_size 能装 100 行，BNL 就得让被驱动表扫 50 遍 —— 每次都是独立的磁盘 IO 或 buffer pool 随机访问。Hash Join 则是：先单次遍历驱动表建哈希表（O(M)），再单次遍历被驱动表做哈希探测（O(N)）。IO 和 CPU 压力直接断崖下降。
EXPLAIN 中看不到 Using join buffer (hash join)？你可能没用对命令
EXPLAIN 默认输出不显示 Hash Join 是否启用，必须用 EXPLAIN FORMAT=TREE 才能看到 Inner hash join 节点。如果只看传统 EXPLAIN 的 Extra 字段，出现 Using join buffer (Block Nested Loop) 是 BNL，但不代表 Hash Join 没生效 —— 它可能已被优化器静默替换，只是旧格式不体现。验证是否真走 Hash Join，只认 FORMAT=TREE 或 EXPLAIN ANALYZE 输出里的 hash join 关键字。
为什么有索引时 MySQL 往往不走 Hash Join？
优化器优先选 Index Nested-Loop Join（INLJ）不是因为“不喜欢”Hash Join，而是因为索引查找更可控、内存开销更低、且不受 join_buffer_size 限制。即使 Hash Join 在某些回表多的场景下反而更快（比如被驱动表大、索引区分度低），优化器仍倾向 INLJ —— 它更稳定。你可以用 IGNORE INDEX 强制禁用索引，再对比 EXPLAIN FORMAT=TREE 输出，观察是否切到 Hash Join。但注意：IGNORE INDEX 是调试手段，线上慎用。
驱动表选错或内存不够，Hash Join 会悄悄退化
Hash Join 不是“开了就稳”。它依赖两个关键条件：一是驱动表足够小（能放进内存哈希表），二是关联字段无可用索引。如果驱动表太大，超出 join_buffer_size，MySQL 会自动分块处理，甚至退回到磁盘哈希或 BNL；LEFT/RIGHT JOIN 中若右表/左表被迫当驱动表，也可能抑制 Hash Join。所以实际执行计划里看到 hash join，不代表全程都在内存中跑 —— EXPLAIN ANALYZE 里的 disk-swap 或高 buffer_used 值才是真实信号。
