MySQL Hash Join 什么时候会消耗大量内存

MySQL Hash Join 容易出现明显内存压力，通常不是因为“看到 Hash Join 就必然吃满内存”，而是构建端数据量大、参与哈希的行较宽、一个计划里有多个连接节点，或者许多会话同时执行这类查询。join_buffer_size 控制单个 Hash Join 可使用的内存上限；复杂多表连接和并发会话会让多个缓冲叠加，超出单节点缓冲后还可能转为磁盘文件。

MySQL 8.4 官方文档：https://dev.mysql.com/doc/refman/8.4/en/hash-joins.html

系统变量说明：https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html

先看懂 Hash Join 的内存边界

Hash Join 会选择一侧输入建立内存中的哈希结构，再用另一侧输入的连接键查找匹配项。执行计划里，Hash 节点下面的子树就是构建输入；构建端越大，哈希桶、键和需要保留的行数据通常越多。

MySQL 8.4 手册明确说明：Hash Join 的内存由 join_buffer_size 控制，单个 Hash Join 不能使用超过这个值的连接缓冲。需要的空间超过可用缓冲时，MySQL 会使用磁盘文件。因此它既是单节点的内存边界，也间接影响是否发生磁盘溢写。

旧认识为什么容易低估总开销

最常见的误解是把 join_buffer_size 当成“每条 SQL 最多使用这么多内存”。官方变量说明给出的边界更细：没有索引的完整连接会为每个表间连接分配一个连接缓冲；复杂查询如果有多个无法使用索引的连接，可能需要多个缓冲。换句话说，它不是整个语句、整个会话或整个服务器的统一上限。

另一个误解是把配置值直接等同于已分配内存。Hash Join 的连接缓冲按需递增分配，小查询不会因为全局值较大就立即占满整个上限。但在大构建端、多连接节点和高并发同时出现时，这个上限仍会被反复放大。

什么时候内存会明显放大

做容量判断时可以先用一个保守的思路：单节点上限 × 单语句连接缓冲数量 × 同类查询峰值并发。这不是实际分配量，因为缓冲按需增长，计划节点也未必同时达到上限；它更适合作为排查服务器最坏压力的预算框架。

先用执行计划确认构建端

不要只看传统 EXPLAIN 的 Using join buffer (hash join)。树形计划更适合看构建端与多层 Hash Join。以下语句不会执行查询，只展示优化器计划：

-- 查看 Hash 节点、构建端子树以及多层连接结构
EXPLAIN FORMAT=TREE
SELECT o.id, o.customer_id, c.level
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= '2026-09-01';

阅读时先找 Hash，再看它下面是哪张表、过滤条件是否已经下推、估算行数是否异常。若计划中出现多个 Hash，就不能再用“一个查询只有一个 join buffer”的假设。

EXPLAIN ANALYZE 会实际执行语句并显示运行信息，适合在可控环境或经过评估的生产查询上核对估算偏差。不要对未知成本的重查询直接执行。

-- 会真正执行 SELECT，用于核对实际行数与循环次数
EXPLAIN ANALYZE
SELECT o.id, o.customer_id, c.level
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= '2026-09-01';

降低内存的顺序比直接调大参数更重要

Hash Join 常用于连接条件没有可用索引的场景。官方变量说明也把“添加合适索引”放在加大连接缓冲之前。一个稳妥的处理顺序如下：

1. 确认连接索引：等值连接键若适合索引访问，优先建立并验证索引，让优化器有机会选择更小成本的访问路径。
2. 缩小构建输入：把选择性高的条件放到能够下推的位置，避免先建立大哈希表再做后置过滤。
3. 减少参与列：避免无目的的 SELECT *，只返回业务需要的字段。
4. 更新统计信息：统计信息严重失真时，优化器可能误判输入规模；在变更窗口评估并执行统计信息维护。
5. 拆分并发峰值：报表、批处理和在线请求同时触发大连接时，限流往往比无限增大缓冲更可靠。

-- 在维护窗口更新表统计信息，帮助优化器重新估算输入规模
ANALYZE TABLE orders, customers;

-- 核对当前会话实际看到的连接缓冲配置
SELECT @@SESSION.join_buffer_size AS session_join_buffer_size;

需要调大时优先限定作用范围

MySQL 8.4 的 join_buffer_size 默认值是262144字节，也就是256 KiB，并支持 Global、Session 和 SET_VAR 查询提示。官方建议保持全局值较小，只对确实需要大连接的会话或单条查询放大；全局设置过大不仅增加并发时的内存预算，还可能因为不必要的分配成本降低性能。

-- 只在当前查询中把连接缓冲上限提高到 8 MiB
SELECT /*+ SET_VAR(join_buffer_size=8388608) */
       o.id, c.level
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= '2026-09-01';

-- 会话级调整适合受控批处理，结束连接后不会影响其他会话
SET SESSION join_buffer_size = 8 * 1024 * 1024;

调大缓冲的目标应是减少已确认的磁盘溢写，而不是让所有 Hash Join 常驻大内存。若查询仍然产生庞大构建端，继续增大参数只是把压力从磁盘移回内存。官方文档还提醒：溢写产生的文件数量可能触及 open_files_limit，此时连接甚至可能失败。

快速判断清单

• EXPLAIN FORMAT=TREE 里有几个 Hash 节点？
• 每个 Hash 子树下面的构建输入估算行数是否异常？
• 连接键是否缺少可用索引，或者索引因类型、字符集、表达式不一致而不可用？
• 查询是否返回了不需要的大字段或全部列？
• 同类语句峰值并发是多少，单次执行持续多久？
• 调大 join_buffer_size 后，磁盘 I/O 是否下降，服务器总内存是否仍有余量？

常见问题

join_buffer_size 是每个连接还是每个会话？

它是连接缓冲的大小控制项。复杂语句可能为多个无索引连接分配多个缓冲，所以不能把它理解成整个会话只有一份。

Hash Join 溢写到磁盘就不会占内存了吗？

不会。它仍会使用受限的内存缓冲，只是把超出可用空间的数据处理转移到磁盘文件；资源压力从纯内存变成内存、I/O 和文件数量的组合。

关闭 Hash Join 能解决内存问题吗？

可以作为诊断对照，但不应替代索引、过滤、统计信息和并发治理。关闭后优化器会选择其他连接方式，可能降低内存，也可能显著增加扫描和执行时间，必须基于计划和业务负载判断。