join_buffer_size只对未走索引的bnl连接生效，需先确认explain中出现“using join buffer”；修改须在join前用set session设置，且需警惕多bnl阶段导致内存峰值激增，优先优化索引而非盲目调大。
join_buffer_size 为什么改了不生效？
MySQL 的 join_buffer_size 是会话级变量，但**只对未使用索引的 JOIN 生效**。如果你的表加了合适索引，优化器压根不会用 join buffer，此时调大它毫无意义。常见错误是看到慢 JOIN 就盲目调参，结果发现 SHOW STATUS LIKE 'Select_full_join'; 一直在涨——说明全连接没走索引，这时才轮到 join_buffer_size 发挥作用。
- 必须先确认是否真触发了 Block Nested-Loop Join（BNL），查
EXPLAIN 输出中 Extra 字段含 Using join buffer (Block Nested Loop)
- 修改需在 JOIN 执行前设置：
SET SESSION join_buffer_size = 4194304;（4MB），不能在查询中动态改
- 全局设置
SET GLOBAL join_buffer_size = ... 不影响已存在的连接，新会话才继承
设多大才算安全？别碰 256MB 这条红线join_buffer_size 是**每个参与 BNL 的驱动表连接独占分配**，不是整个查询共用。比如一个三表 JOIN（t1 JOIN t2 JOIN t3），若 t1→t2 和 t2→t3 都走 BNL，则最多可能同时占用 2 × join_buffer_size 内存。
- 默认值通常 256KB，对小表够用；线上调大建议控制在 1–8MB 区间，超过 16MB 要警惕
- 单次查询若涉及 N 个 BNL 阶段，峰值内存 ≈ N ×
join_buffer_size，而 MySQL 没有 per-query 内存限额机制
- 曾见配置 256MB 后，突发多个复杂 JOIN 并发，瞬间吃光 64GB 物理内存，触发 OOM Killer 杀掉 mysqld 进程
替代方案比硬调 join_buffer_size 更靠谱
真正要防内存溢出，优先砍掉 BNL 场景本身，而不是给它更多缓冲区。
- 给被驱动表的关联字段补上索引，让 NL（Nested-Loop）变 Index Nested-Loop，直接绕过 join buffer
- 用
STRAIGHT_JOIN 强制驱动表顺序，避免优化器选错小表当被驱动方
- 大表 JOIN 前先用
WHERE 过滤，减少驱动表结果集大小——buffer 是按驱动表批次加载的，输入越小，buffer 压力越低
- 实在无法加索引，考虑拆成应用层分页 JOIN 或临时表预聚合，比赌 buffer 不爆更可控
监控和告警必须盯住这两个指标
光调参数不看效果等于盲操作。上线后重点观察：
-
SHOW GLOBAL STATUS LIKE 'Select_full_join';：持续增长说明索引缺失或统计信息过期，该更新 ANALYZE TABLE
-
performance_schema.memory_summary_by_thread_by_event_name 中匹配 memory/sql/join_cache 的分配总量，能真实反映各线程 buffer 消耗，比估算靠谱得多
EXPLAIN 输出中 Extra 字段含 Using join buffer (Block Nested Loop)
SET SESSION join_buffer_size = 4194304;（4MB），不能在查询中动态改SET GLOBAL join_buffer_size = ... 不影响已存在的连接，新会话才继承join_buffer_size 是**每个参与 BNL 的驱动表连接独占分配**，不是整个查询共用。比如一个三表 JOIN（t1 JOIN t2 JOIN t3），若 t1→t2 和 t2→t3 都走 BNL，则最多可能同时占用 2 × join_buffer_size 内存。
- 默认值通常 256KB，对小表够用；线上调大建议控制在 1–8MB 区间，超过 16MB 要警惕
- 单次查询若涉及 N 个 BNL 阶段，峰值内存 ≈ N ×
join_buffer_size，而 MySQL 没有 per-query 内存限额机制 - 曾见配置 256MB 后，突发多个复杂 JOIN 并发，瞬间吃光 64GB 物理内存，触发 OOM Killer 杀掉 mysqld 进程
替代方案比硬调 join_buffer_size 更靠谱
真正要防内存溢出，优先砍掉 BNL 场景本身，而不是给它更多缓冲区。
- 给被驱动表的关联字段补上索引，让 NL（Nested-Loop）变 Index Nested-Loop，直接绕过 join buffer
- 用
STRAIGHT_JOIN 强制驱动表顺序，避免优化器选错小表当被驱动方
- 大表 JOIN 前先用
WHERE 过滤，减少驱动表结果集大小——buffer 是按驱动表批次加载的，输入越小，buffer 压力越低
- 实在无法加索引，考虑拆成应用层分页 JOIN 或临时表预聚合，比赌 buffer 不爆更可控
监控和告警必须盯住这两个指标
光调参数不看效果等于盲操作。上线后重点观察：
-
SHOW GLOBAL STATUS LIKE 'Select_full_join';：持续增长说明索引缺失或统计信息过期，该更新 ANALYZE TABLE
-
performance_schema.memory_summary_by_thread_by_event_name 中匹配 memory/sql/join_cache 的分配总量，能真实反映各线程 buffer 消耗，比估算靠谱得多
STRAIGHT_JOIN 强制驱动表顺序，避免优化器选错小表当被驱动方WHERE 过滤，减少驱动表结果集大小——buffer 是按驱动表批次加载的，输入越小，buffer 压力越低-
SHOW GLOBAL STATUS LIKE 'Select_full_join';：持续增长说明索引缺失或统计信息过期，该更新ANALYZE TABLE -
performance_schema.memory_summary_by_thread_by_event_name中匹配memory/sql/join_cache的分配总量，能真实反映各线程 buffer 消耗，比估算靠谱得多
MySQL 对 join_buffer_size 的管理很“朴素”——它不回收、不复用、不压缩，一次分配就扛到语句结束。很多人卡在“为什么我只跑一条 SQL 就把内存打满了”，答案往往藏在执行计划里，而不是配置文件里。
