Using join buffer (Block Nested Loop) 表示MySQL正用连接缓冲区做嵌套循环连接，是性能瓶颈信号，主因是被驱动表未走索引；应优先为ON条件字段添加合适索引，而非盲目调大join_buffer_size。
using join buffer (block nested loop) 出现在 navicat 的执行计划 extra 列里，说明 mysql 正在用连接缓冲区做嵌套循环连接——这不是错误，但通常是性能瓶颈的明确信号，尤其当被驱动表没走索引时。
为什么会出现 Using join buffer
本质是 MySQL 在「被驱动表无法用索引快速匹配」时的兜底策略：
- 驱动表（
JOIN左侧或优化器选中的小表）的部分数据被批量读入内存缓冲区（join_buffer） - 被驱动表（右侧）被全表扫描一次，每行都跟缓冲区里的所有驱动表行比对
- 没有索引时，这种“扫一遍被驱动表 + 缓冲区多行匹配”比传统单行嵌套循环省 I/O，但仍是 O(N×M) 级开销
- 常见于
ON或USING条件字段缺失索引、或索引未被命中（如类型不匹配、函数包裹、前导通配符等）
加索引比调 join_buffer_size 更有效
加索引直接让被驱动表从「全表扫描」变成「索引查找」，复杂度从 O(N) 降到 O(log N)，收益远超缓冲区调整：
- 优先检查
ON条件字段是否在被驱动表上有索引，例如SELECT * FROM A JOIN B ON A.id = B.a_id，确保B.a_id有索引 - 复合索引要注意最左前缀：如果条件是
ON B.x = ? AND B.y = ?，单列索引x或y效果有限，应建(x, y)联合索引 - 避免隐式转换：比如
B.col是VARCHAR，但ON里用了数字比较（A.id = B.col），会导致索引失效，Extra仍显示Using join buffer - Navicat 中右键表 → «设计表» → «索引» 标签页可快速添加，无需写
CREATE INDEX
什么时候才该调大 join_buffer_size
仅在加不了索引、且驱动表不大、被驱动表又必须全扫的硬性场景下考虑：
- 默认值是 256KB（
262144字节），对多数中小查询够用；盲目调到几 MB 可能引发内存争抢，尤其并发高时 - 临时修改（当前会话生效）：
SET SESSION join_buffer_size = 4194304;（4MB） - 永久修改需改 MySQL 配置文件（
my.cnf或my.ini）的[mysqld]段：join_buffer_size = 4M，然后重启服务 - 注意：这个变量是「每个连接独享」的，100 个并发连接 × 4MB = 400MB 内存开销，得算清楚
真正卡住性能的往往不是缓冲区大小，而是被驱动表那一次又一次的全表扫描。看到 Using join buffer (Block Nested Loop)，第一反应不该是调参数，而是打开被驱动表的结构页，盯住 ON 字段有没有索引、索引是不是被真正用上——Navicat 的执行计划里 key 列为空、type 是 ALL，就是最直白的提醒。
