join buffer未生效时调大join_buffer_size无效，因其仅在被驱动表无法走索引（type=all或index）时启用；若on字段有有效索引，则走index nested-loop join，buffer大小无影响。
JOIN Buffer没生效时，调大根本没用
很多人一看到EXPLAIN里出现Using join buffer (Block Nested Loop)就急着调大join_buffer_size，但实际效果常不如预期。因为JOIN Buffer只在被驱动表**无法走索引**（即type=ALL或type=index）时才启用。如果被驱动表的ON字段有有效索引，MySQL压根不进JOIN Buffer流程——它走的是Index Nested-Loop Join，此时join_buffer_size再大也白搭。
Buffer大小影响的是“一次能缓多少驱动表数据”
JOIN Buffer本质是把驱动表的部分结果暂存内存，再批量去匹配被驱动表。它的作用不是加速单次匹配，而是减少被驱动表的扫描次数：
- 默认
join_buffer_size=256KB，假设驱动表每行需缓存100字节，则最多缓2560行 - 若驱动表结果集有10万行，就得扫描被驱动表
100000 ÷ 2560 ≈ 39次 - 把
join_buffer_size调到2MB，缓存行数翻8倍，扫描次数降到约5次
但注意：缓冲区越大，单次匹配的CPU计算量越高（内存中做M×N次比对），且可能挤占其他连接内存，线上慎调。
真正卡住性能的从来不是Buffer大小
当EXPLAIN显示key=NULL或rows远超预期，说明被驱动表没走索引。这时调大join_buffer_size只是用内存换I/O，掩盖问题而非解决：
- 字段类型不一致（如
INTvsVARCHAR）导致隐式转换，索引失效 - 联合索引未命中最左前缀，比如ON条件只用了第二列
- 驱动表WHERE过滤后仍返回几万行，结果集过大，Buffer再大也救不了
优先检查EXPLAIN的key和rows列，确认索引是否真实生效。Buffer调优永远排在索引、类型对齐、结果集压缩之后。
