join_buffer_size用于bnl算法中缓存非驱动表数据，仅在无索引join时生效；默认256kb，需按被驱动表扫描行数×字段字节数估算，避免过高导致oom，优先优化索引而非调大该值。
join_buffer_size 是干啥的，什么时候才用得上
MySQL 的 join_buffer_size 只在「非驱动表」没有可用索引、且使用 Block Nested-Loop（BNL）算法做 JOIN 时才会分配。不是所有 JOIN 都走它——如果被 JOIN 的列有索引，优化器大概率选 Index Nested-Loop（INL），这时压根不碰这个 buffer。
常见错误现象：EXPLAIN 显示 type=ALL 或 type=index，且 Extra 列里带 Using join buffer (Block Nested Loop)，但查询又慢得离谱，这时候才值得怀疑 buffer 太小。
- 默认值通常只有 256KB（MySQL 8.0），对稍大点的中间结果根本不够用
- 它是每个线程独享的，不是全局总内存，调太高容易撑爆物理内存
- 只影响单次 JOIN 操作，不会跨语句复用
怎么查当前生效值和是否真在用
先确认 session 级实际值：
SELECT @@join_buffer_size;
别只看
SHOW VARIABLES LIKE 'join_buffer_size'，它可能显示 global 值，而 session 已被显式改过。判断是否真触发了 join buffer：
- 开启
optimizer_trace，执行 JOIN 后查information_schema.OPTIMIZER_TRACE，找join_execution节点里的buffer_usage字段 - 或直接开 performance_schema：
SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%JOIN%';
再结合events_stages_history_long看是否有stage/sql/Creating sort index类等待（间接提示 BNL 在扛压）
调多大才算合理，哪些坑千万别踩
调大小不是越大越好，关键看 JOIN 的「被驱动表扫描行数 × 每行参与 JOIN 的字段字节数」：
- 先估算：比如被驱动表要扫 10 万行，JOIN 条件字段共 20 字节 → 至少需要 2MB 缓冲（100000 × 20 ≈ 2MB）
- 实操建议从 4MB 起试：
SET SESSION join_buffer_size = 4194304;
- 严禁在配置文件里设成几百 MB：
join_buffer_size = 512M看似豪横，但并发 50 个连接就吃掉 25GB 内存，OOM 风险极高 - 不要和
sort_buffer_size混用：两者完全独立，一个管 JOIN，一个管 ORDER BY / GROUP BY - MyISAM 表 JOIN 时该 buffer 效果更差，优先考虑转 InnoDB + 加索引
比调 buffer 更有效的替代方案
绝大多数情况下，调 join_buffer_size 是在给烂索引擦屁股。真正该优先做的：
- 确保被驱动表的 ON 条件列有合适索引（最好是联合索引，覆盖 WHERE + JOIN 字段）
- 避免在 JOIN 条件里写函数：
ON DATE(t1.created) = t2.day会让索引失效，被迫走 BNL - 小表驱动大表：用
STRAIGHT_JOIN强制顺序，让有索引的小表当驱动表 - 实在要 JOIN 大表，考虑提前物化中间结果到临时表，并加索引
buffer 调得再细，也救不了没索引的 JOIN；而一个正确索引，往往让 join_buffer_size 回归默认值都够用。
