join_buffer_size仅在被驱动表type为all或index且explain显示“using join buffer (block nested loop)”时才生效；建议会话级设2m–8m，超32m易oom，优先加索引而非调大该值。
确认 join_buffer_size 真的在起作用
别一上来就改配置，先看它有没有被用上。关键信号只有两个：EXPLAIN 输出中，被驱动表的 type 必须是 ALL 或 index，且 Extra 列明确出现 Using join buffer (Block Nested Loop)。
如果看到的是 Using join buffer (hash join)，说明 MySQL 8.0.20+ 启用了 Hash Join，此时 join_buffer_size 虽仍参与内存分配，但逻辑已不同，优先级让位于整体可用内存；如果 type 是 ref、range 或 eq_ref，那它根本没机会加载数据，调大毫无意义。
常见误判场景：
-
ON UPPER(a.name) = UPPER(b.name)导致索引失效，被迫走 BNL —— 应统一存储大小写，改用直接等值比较 - 被驱动表有复合索引
(status, category_id)，但ON只写了b.category_id = a.id，最左前缀未覆盖 —— 补全条件或调整索引顺序 - 统计信息过期，优化器误判成本，执行
ANALYZE TABLE b后Using join buffer消失 —— 这恰恰说明原本就不该依赖它
设多大才算合理：避开 32M 红线
join_buffer_size 是线程级变量，每个连接独占一份内存。默认值（256K 或 512K）对现代业务普遍偏小，但盲目加大极易引发 OOM。
建议范围：单次会话设为 2M–8M，例如：SET SESSION join_buffer_size = 4194304。
超过 32M 极少带来收益，反而容易触发 ERROR 5 (HY000): Out of memory，尤其在高并发下 —— 100 个并发 × 16M = 1.6GB 内存直接被预占。
绝对不要在全局配置（my.cnf）里设高值。线上应优先用 SESSION 级设置，仅对确认走 BNL 的慢查询临时生效。
比调大小更有效的三件事
加索引永远比调 join_buffer_size 更安全、更有效。BNL 是兜底策略，不是首选方案。
真正该优先做的：
- 确保被驱动表连接列上有可用索引，触发
INLJ（索引嵌套循环），让type从ALL降为ref或eq_ref - 检查驱动表是否真的“小”：优化器选错驱动表时，
STRAIGHT_JOIN比调缓冲区更直接 - 关闭不必要的字段：SELECT 中只取需要的列，减少
join_buffer单次缓存的数据体积，变相提升命中率
如果驱动表本身超百万行，即使被驱动表有索引，优化器也可能因成本估算偏差选错顺序 —— 此时强行调大 join_buffer_size 只会让内存压力雪上加霜。
配合监控验证效果
改完不能只看“有没有报错”，要观察实际行为变化：
- 关注
Handler_read_next是否显著下降：说明被驱动表扫描次数减少了 - 查慢查询日志，确认是否还有“小驱动表 + 大量回查被驱动表”的模式反复出现
- 对比
SHOW STATUS LIKE 'Created_tmp_disk_tables'，若该值上升，说明临时表溢出到磁盘，可能tmp_table_size或max_heap_table_size也需同步评估
真正难的从来不是设个数字，而是判断“此刻到底该不该让它工作”。一旦索引到位、驱动表合理、条件干净，join_buffer_size 就该安静待命 —— 它不是加速器，是最后一道缓冲带。
