join_buffer_size仅在被驱动表无索引导致bnlj时生效，缓存越小则驱动表分段越多、被驱动表全表扫描越频繁，i/o与cpu开销倍增；调大可减少扫描轮次，但需配合explain确认“using join buffer”且避免并发oom。
Join Buffer Size 为什么会影响联表查询效率
因为 MySQL 在没有索引可用时，会退化到 Block Nested-Loop Join（BNLJ）算法，而该算法依赖 join_buffer_size 缓存驱动表数据——缓存越小，驱动表就得被分段多次加载，被驱动表就得被反复全表扫描，I/O 和 CPU 开销呈倍数增长。
什么情况下 join_buffer_size 才真正起作用
它只在以下场景生效：
- 被驱动表的关联字段没有索引（导致无法走 Index Nested-Loop Join）
- 驱动表是 ALL / index / range 访问类型（即需要全表或范围扫描）
- 执行计划中出现
Using join buffer (Block Nested Loop)或Using join buffer (hash join) - MySQL 版本为 5.7（BNLJ）或 8.0+（Hash Join），且未启用 BKA（Batched Key Access）
如果被驱动表上有可用索引，join_buffer_size 调大毫无意义——优化器根本不会用它。
调大 join_buffer_size 的实际代价和风险
每个 JOIN 操作都会独占一个 Join Buffer，且是 per-connection 分配。盲目调大会引发内存争抢甚至 OOM：
- 默认值仅
256k（mac）或512k（Linux），对小表 JOIN 影响不大 - 设为
16M后，1 万个并发连接可能瞬时占用 160GB 内存（16M × 10000） - 官方建议：
join_buffer_size总用量不超过物理内存的 50% - 更安全的做法是：全局设保守值（如
2M），仅在明确慢 SQL 的 session 中临时调高，例如：SET SESSION join_buffer_size = 8388608;
怎么确认你是否真需要调这个参数
别猜，看 EXPLAIN 和实际执行计划：
- 运行
EXPLAIN FORMAT=TRADITIONAL SELECT ... JOIN ...，检查Extra列是否含Using join buffer - 用
SHOW PROFILE FOR QUERY N或 Performance Schema 查看Handler_read_next和Handler_read_rnd_next是否异常高（说明被驱动表被反复扫描） - 对比加索引 vs 加 buffer 的收益：加一个二级索引通常比把
join_buffer_size从 256k 调到 4M 更有效、更稳定
真正卡住性能的，往往不是 buffer 太小，而是关联字段没索引、驱动表选得不合理、或者查询本身返回了过多冗余字段——这些比调参更容易见效，也更不容易翻车。
