JOIN缓冲区溢出典型表现为查询卡顿、SHOW PROCESSLIST显示大量线程卡在Sending data或Copying to tmp table，Rows_examined异常高，严重时mysqld被OOM Killer杀死；根本原因是被驱动表缺索引导致全表扫描载入内存，而非join_buffer_size配置过小。
别急着调大 join_buffer_size —— 它只在被驱动表全表扫描且没走索引时才生效，多数“Buffer不足”其实是索引或写法问题暴露出来的假象。
确认是否真用上了 Join Buffer
MySQL 不是每个 JOIN 都走 Block Nested-Loop（BNL），只有当被驱动表无法用索引定位行时才会退化至此。盲目调参前，必须验证执行计划里是否真的触发了它：
- 运行
EXPLAIN，重点看被驱动表那一行的type是否为ALL或index，且Extra中明确出现Using join buffer (Block Nested Loop) - 如果
Extra里是Using where; Using index或Using index condition，说明走了 Index Nested-Loop（NLJ），join_buffer_size完全不参与，调它没用 - 常见误判：ON 条件用了函数（如
ON UPPER(a.name) = UPPER(b.name)）、连接字段类型不一致（INT vs VARCHAR）、复合索引未覆盖最左前缀——这些都会让索引失效，逼出 BNL，但根因不是 buffer 小
优先修复索引和连接写法
绝大多数“Join Buffer 不足”背后，是本该走索引却没走。buffer 只是兜底机制，不是主加速路径：
- 确保被驱动表的 ON 字段有**单列索引或复合索引的最左前缀**，例如
JOIN orders o ON u.id = o.user_id，就要在orders.user_id上建索引 - 检查连接字段类型、字符集、是否允许 NULL —— 任一不一致都可能触发隐式转换，导致索引失效
- LEFT JOIN 的过滤条件尽量写进
ON而非WHERE，否则会先生成大量 NULL 行再过滤，徒增 buffer 压力 - 避免
SELECT *，只查必需字段；过长的VARCHAR或TEXT字段会让每行占用更多 buffer 空间，更快溢出
合理设置 join_buffer_size（仅当确认启用 BNL 后）
它是线程级变量，每个连接独占一份内存，高并发下极易引发 OOM：
- 默认
256KB太小，线上建议设为2M–8M（如SET SESSION join_buffer_size = 4194304），别全局设高值 - 超过
32M极少带来收益，反而可能因内存分配失败直接报错ERROR 5 (HY000): Out of memory - 不要在
my.cnf里设成64M或更高 —— 100 个并发连接就吃掉 6.4GB 内存 - 配合监控：观察
Handler_read_next是否显著下降，以及慢查日志中是否还有“驱动表小但被驱动表反复全扫”的模式
容易被忽略的关键点
真正卡住性能的，往往不是 buffer 大小本身，而是它背后暴露的更深层问题：
-
join_buffer_size和sort_buffer_size、tmp_table_size不冲突，但会抢同一块物理内存；单条查询可能同时用到三者，总内存压力得算总账 - 统计信息过期会导致优化器误判，明明有索引却选了 BNL；执行
ANALYZE TABLE后 BNL 消失，join_buffer_size就彻底闲置了 - MySQL 8.0+ 支持 Hash Join，对大表无索引场景更高效；但需确认版本和
optimizer_switch设置，不能指望 buffer 替代算法升级
