Hash Join比BNL快的根本原因是将O(M×N)降为O(M+N)，避免被驱动表重复全表扫描与IO；BNL因join_buffer_size限制需分批处理，导致被驱动表被反复扫描数十次，而Hash Join仅需单次构建哈希表和单次探测。
Hash Join 能让无索引连接查询提速，根本原因不是“用了新算法”，而是它彻底绕开了被驱动表反复全表扫描这个IO瓶颈。只要被驱动表没索引，BNL 就得扫几十遍，而 Hash Join 只扫一遍。
为什么BNL在无索引时实际要扫被驱动表几十次
Block Nested-Loop Join（BNL）看着是“批量”，但本质仍是“驱动表分批 → 被驱动表反复全扫”。关键在于：join_buffer_size 决定了每次能塞多少驱动表行进内存缓冲区；剩下的就得等下一批。
- 假设驱动表过滤后剩 8000 行，
join_buffer_size = 2M，每行约 200 字节 → 一次最多缓存约 1000 行 - 那就得分 8 批处理 → 被驱动表被完整扫描 8 次
- 每次扫描都触发随机页读取（哪怕部分页在 buffer pool，仍需大量
latch和page lookup） -
EXPLAIN中看到Using join buffer (Block Nested Loop)就是它在干活
Hash Join怎么做到只扫被驱动表一次
它把“重复比对”变成“一次建表 + 一次探测”：先用驱动表建哈希表（Build Phase），再用被驱动表逐行算 hash 去查（Probe Phase）。
- 建表过程：单次遍历驱动表，以关联字段（如
country_id）为 key，构造内存哈希表，时间复杂度O(M) - 探测过程：单次遍历被驱动表，每行计算
HASH(country_id)→ 查内存桶 → 匹配输出，时间复杂度O(N) - 总开销趋近
O(M + N)，而非O(M × N)；IO 从“M/N 次全表扫描”降为“各扫一次” -
EXPLAIN中出现Using join buffer (hash join)才表示真正启用
什么情况下MySQL会拒绝走Hash Join
优化器不是无脑选 Hash Join，它会权衡内存、数据分布和语义完整性。常见绕过场景：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 被驱动表关联字段**有可用索引** → 优先选
Index Nested-Loop Join（INLJ），因更稳定、内存开销更低 - 驱动表太大，超出
join_buffer_size且无法有效分片 → 可能退化为磁盘哈希或改用 NLJ - LEFT/RIGHT JOIN 中驱动方向与哈希构建逻辑冲突（如右表本该是构建表，但 LEFT JOIN 要求左表驱动）→ 抑制 hash join
- 隐式类型转换导致关联字段无法走索引 → 间接让优化器误判“有索引可用”，从而跳过 Hash Join；此时
SHOW WARNINGS常能看到类型不匹配提示
怎么确认并微调Hash Join是否真生效
不能只看 SQL 写法或版本号，得盯住执行计划和运行时参数：
- 用
EXPLAIN FORMAT=TRADITIONAL或EXPLAIN ANALYZE，重点看Extra列是否含hash join - 检查
join_buffer_size：太小（如默认 256K）会导致哈希表被迫分片，性能打折；建议设为4M~32M（根据可用内存调整） - 强制指定可用
/*+ HASH_JOIN(t1, t2) */提示，但仅当确定驱动表较小、无索引、且你愿意承担内存风险时才用 - 如果本该走 hash 却走了
BNL或NLJ，优先查SHOW INDEX FROM table_name和SHOW WARNINGS，常因统计信息陈旧或字段类型不一致导致索引失效
真正容易被忽略的点是：Hash Join 的收益高度依赖“驱动表是否真的小”和“内存是否够用”。很多线上慢查优化失败，不是因为没开 8.0，而是驱动表选错了、join_buffer_size 没调、或者关联字段悄悄加了索引却没意识到它反而关掉了 Hash Join。
