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 消耗，比估算靠谱得多

MySQL 对 join_buffer_size 的管理很“朴素”——它不回收、不复用、不压缩，一次分配就扛到语句结束。很多人卡在“为什么我只跑一条 SQL 就把内存打满了”，答案往往藏在执行计划里，而不是配置文件里。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载