MySQL 哈希连接在什么条件下生效

有一次排查两张大表的查询计划时，最容易误判的现象是：执行计划里出现了 Inner hash join，于是马上把原因归结为“没有索引”。实际情况要更细一点：MySQL 8.4 默认会在可行时使用哈希连接，典型条件是连接谓词包含等值比较，同时连接条件上没有适合直接使用的索引；但非等值连接、外连接和没有显式连接条件的笛卡尔积也可能进入哈希连接路径。最终是否采用，仍由优化器的成本判断、开关和内存边界共同决定。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/hash-joins.html

判断 MySQL 哈希连接是否生效，先看连接条件，再看连接列是否有可用索引，然后确认 block_nested_loop 没有被关闭，最后用 EXPLAIN FORMAT=TREE 看实际计划。不要只改一个开关，更不要把 HASH_JOIN 当成 MySQL 8.4 的有效控制项。

先从症状区分哈希连接与索引连接

排查通常从一个可见症状开始：同一条 SQL 在数据量变大后，执行计划不再展示基于索引的逐行查找，而是出现 Inner hash join 或 Left hash join。这并不直接说明计划错误，也不意味着建立任意索引就会强制替换它。MySQL 使用成本型优化器，连接顺序、过滤后的行数、统计信息和缓冲区预算都会影响选择。

我会先把问题拆成三层：SQL 是否给出了可用于连接的谓词，连接列上是否真的存在适用索引，以及当前会话是否允许连接缓冲优化。这样能避免把“哈希连接出现了”和“索引没有生效”混成同一件事。

检查连接条件和可用索引

最典型的候选是两张表通过连接列做等值比较，且没有适合连接条件的索引：

-- 这个示例只用于说明连接条件；不要把示例计划当成实测结果
SELECT o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.customer_id;

如果 o.customer_id 或 c.customer_id 上存在可直接应用的索引，优化器可能更倾向索引连接；如果没有，或者索引对当前连接条件并不适用，哈希连接就可能成为候选。这里的关键词是“可能”，因为优化器还会比较过滤后行数和估算成本。

不要把条件理解得过窄。MySQL 8.4 文档说明，哈希连接也可以出现在以下场景：

• 连接中带有等值条件，同时附带其他过滤条件；额外条件可能在连接后作为过滤处理。
• 内连接只有非等值条件，例如 o.amount 。
• 左外连接、右外连接，以及半连接、反连接等外连接形态。
• 没有连接条件的笛卡尔积，但这通常需要非常谨慎地评估结果规模。

因此，“没有等号就一定不能哈希连接”与“只要有等号就一定会哈希连接”都是过度简化。真正要确认的是：连接条件能否形成可行的哈希候选，以及成本模型有没有更合适的访问路径。

确认 block_nested_loop 与 BNL 控制项

MySQL 8.4 里，控制哈希连接的关键开关是 block_nested_loop。名字保留了历史上的块嵌套循环语义，但官方文档明确说明它也控制哈希连接；对应的提示是 BNL 和 NO_BNL。

-- 先查看当前会话的优化器开关，避免误读全局配置
SELECT @@SESSION.optimizer_switch;

-- 只在确认需要测试时，对当前会话打开哈希连接相关控制项
SET SESSION optimizer_switch = 'block_nested_loop=on';

-- 该提示用于当前语句；别把它当成永久配置
SELECT /*+ BNL(c) */
       o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.customer_id;

反过来，NO_BNL 可以用于对照实验，观察关闭连接缓冲优化后计划如何变化：

-- 对照实验只影响这条语句，便于比较计划差异
SELECT /*+ NO_BNL(c) */
       o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.customer_id;

不要在 MySQL 8.4 里依赖 HASH_JOIN 或 NO_HASH_JOIN 提示来完成这件事。官方优化器提示文档标明，这两个提示在 8.4 没有作用；应使用 BNL 或 NO_BNL。此外，改开关前要确认是当前会话还是全局配置，避免排查动作影响其他连接。

用 EXPLAIN FORMAT=TREE 复查实际计划

条件满足只是候选，最后还要看优化器给出的计划。树形输出比传统表格更容易直接识别连接类型：

-- 树形计划用于观察连接算法、连接顺序和附加过滤
EXPLAIN FORMAT=TREE
SELECT o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.customer_id;

-- 需要运行时信息时再使用 ANALYZE；本文不把示例输出当成实测结果
EXPLAIN ANALYZE
SELECT o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.customer_id;

你需要重点寻找 Inner hash join、Left hash join 或其他包含 hash join 的节点，同时对照子节点的表扫描、过滤和连接列。若 SQL 同时有等值和非等值条件，树形计划可能把非等值部分体现为连接后的过滤；这不代表非等值条件消失了，而是它承担的角色与建立哈希键的等值条件不同。

如果计划没有采用哈希连接，按这个顺序排查：连接列是否有可用索引、统计信息是否过期、block_nested_loop 是否关闭、连接顺序是否导致成本改变，以及是否存在更强的过滤条件。不要仅凭某一次计划就断言“永久不会使用哈希连接”。

处理 join_buffer_size 与磁盘溢写

哈希连接不是没有成本。MySQL 使用 join_buffer_size 控制哈希连接可使用的内存；当所需内存超过可用连接缓冲时，可能转为使用磁盘文件。此时查询仍可能完成，但临时文件、文件句柄和 I/O 会把“算法更适合”变成“资源更紧张”。

-- 查看当前会话的连接缓冲预算，先记录再决定是否调整
SELECT @@SESSION.join_buffer_size;

-- 只给当前会话设置测试值；生产环境应结合并发连接数评估
SET SESSION join_buffer_size = 4 * 1024 * 1024;

调大 join_buffer_size 不是万能修复。并发较高时，每个连接都可能产生额外内存压力；外连接还可能一次性分配整个缓冲区。更稳妥的做法是先缩小参与连接的数据量、补充准确统计信息、确认索引是否真的适合，再用计划和资源指标判断是否需要提高预算。

如果确实发生磁盘溢写，复查的不只是缓冲区，还包括 open_files_limit 和查询并发。文章中的结构图把这些关系画成静态边界，是为了帮助定位资源责任，不代表某一次运行一定会产生磁盘文件。

一份可复用的复查清单

1. 先确认 SQL 的连接对象、连接列和过滤范围，明确是否是等值、非等值、外连接或无条件连接。
2. 分别检查两侧连接列的索引定义与实际可用性，不把“存在索引”直接等同于“优化器会采用”。
3. 读取当前会话的 optimizer_switch，确认 block_nested_loop 没有被关闭。
4. 用 EXPLAIN FORMAT=TREE 对照连接节点；需要运行时数据时，再单独安排 EXPLAIN ANALYZE。
5. 若看到哈希连接，继续检查 join_buffer_size、并发量和潜在磁盘溢写，不要只看 CPU 时间。
6. 对照修改前后的计划与资源指标，保留会话级实验记录，避免直接改变全局配置。

归纳起来，MySQL 哈希连接“生效”不是单一开关决定的结果：连接条件提供候选，索引可用性改变成本，block_nested_loop 决定优化路径是否开放，join_buffer_size 决定资源边界，而 EXPLAIN FORMAT=TREE 才能告诉你最终计划。把这几层分开看，排查就不会停留在“为什么没走索引”或“为什么突然用了 Hash Join”的单点猜测上。

相关问题

有等值连接条件就一定会使用哈希连接吗？

不一定。若连接条件上有合适索引，或者成本模型判断其他访问路径更便宜，优化器可能选择索引连接或其他方案。

MySQL 8.4 还能用 HASH_JOIN 提示吗？

官方文档说明 HASH_JOIN 与 NO_HASH_JOIN 在 MySQL 8.4 无效。需要控制哈希连接时，使用 BNL、NO_BNL 或 block_nested_loop。

哈希连接一定比嵌套循环连接快吗？

不一定。连接两侧规模、过滤选择性、索引、内存预算和并发都会改变结果，最终应以执行计划和实际资源表现综合判断。