join_buffer_size仅在被驱动表无索引、启用BNL算法时生效，需通过EXPLAIN确认“Using join buffer”才调整；默认256KB，建议按需设为1M–4M，优先优化索引而非盲目调大。
直接调大 join_buffer_size 并不一定让 JOIN 更快，甚至可能拖慢整体性能——关键看它是否被真正用上、用得是否合理。
什么时候 join_buffer_size 才起作用？
它只在被驱动表**没有可用索引**时生效，此时 MySQL 启用 Block Nested-Loop Join（BNL）算法，把驱动表的部分数据缓存到 Join Buffer 中，减少对被驱动表的重复全表扫描。
- 如果被驱动表的 ON 字段有索引（比如
idx_user_id），MySQL 会走 Index Nested-Loop Join（INLJ），根本不用join_buffer_size - 如果用了
STRAIGHT_JOIN强制小表驱动，但被驱动表仍无索引，这时才依赖该参数 -
EXPLAIN输出中Extra列出现Using join buffer (Block Nested Loop)，才是它正在工作的信号
怎么判断当前值是否合适？
不能凭空设个“4M”就完事。先查监控指标，再针对性调整：
- 运行
SHOW STATUS LIKE 'Created_tmp_disk_tables';，值持续增长说明 Join Buffer 不够，溢出到磁盘临时表 - 检查
Handler_read_next和Handler_read_rnd_next的比值，后者过高常意味着 BNL 频繁触发 - 观察
join_buffer_size是否远大于实际所需：每个 JOIN 操作独占一份 Buffer，设太大容易浪费内存，尤其并发高时
设置多大才算合理？
没有固定值，取决于驱动表每次批量读入的数据量和并发数：
- 默认是 256KB，对多数中小 JOIN 足够；若
EXPLAIN显示频繁使用磁盘临时表，可尝试升到 1M～4M - 不要超过单次 JOIN 驱动表结果集的估算大小（比如驱动表过滤后剩 500 行，每行平均 200 字节 → 约 100KB，设 1M 已绰绰有余）
- 全局设置风险高，建议优先用
SET SESSION join_buffer_size = 2097152;在具体慢查询前临时调大 - MySQL 8.0+ 如果被驱动表有索引且满足条件，会自动启用更高效的 Hash Join，此时
join_buffer_size完全不参与
最容易被忽略的是：调大这个参数治标不治本。真正该优先做的，是确保被驱动表连接字段有索引，并验证优化器是否真的选对了驱动表——join_buffer_size 只是兜底手段，不是提速主力。
