JOIN缓冲区溢出典型表现为查询卡顿、SHOW PROCESSLIST显示大量线程卡在Sending data或Copying to tmp table，Rows_examined异常高，严重时mysqld被OOM Killer杀死；根本原因多是被驱动表缺索引导致全表扫描载入内存，而非join_buffer_size配置过小。
JOIN缓冲区溢出的典型表现是什么
执行 JOIN 时卡住、查询变慢、SHOW PROCESSLIST 中大量线程卡在 Sending data 或 Copying to tmp table 状态，且 Rows_examined 异常高；更严重时 MySQL 进程被系统 OOM Killer 杀掉，dmesg 输出里出现 Out of memory: Kill process ... (mysqld) —— 这说明不是 SQL 写得差，而是内存分配机制撑不住了。
为什么调 join_buffer_size 很容易白忙活
这个参数只对 **未命中索引的 JOIN** 生效（比如 ON t1.a = t2.b，但 t2.b 没索引），它控制每个连接为被驱动表分配的“朴素嵌套循环”内存缓冲。但现实中绝大多数 JOIN 溢出，根本不是因为这个值太小，而是：
- 被驱动表缺少关联字段索引 → 触发全表扫描 + 全量载入
join_buffer→ 即使设成 64M 也扛不住百万行 -
join_buffer_size是「每连接独占」的，max_connections=500时，500 × 64MB = 32GB，远超物理内存 - MySQL 8.0.22+ 已默认禁用
Block Nested-Loop，改用更省内存的Hash Join，此时该参数完全不生效
所以别一上来就改 join_buffer_size，先确认执行计划：EXPLAIN FORMAT=TREE 看是否真在用 Block Nested-Loop；否则调它只是给 OOM 加速。
真正有效的三步处理路径
优先级从高到低：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
加索引：确保被驱动表的
ON/WHERE字段有索引，这是最直接的解法。例如JOIN users u ON o.user_id = u.id，必须保证users.id是主键或有索引，orders.user_id也要有索引 -
换驱动表：用
STRAIGHT_JOIN强制指定驱动表，让小结果集做外层循环。比如SELECT STRAIGHT_JOIN ... FROM small_table s JOIN huge_table h ON ... -
分批查 + 应用层合并：当无法加索引或数据量实在太大（如日志类表），就放弃单条 JOIN，改用主键范围分片：
SELECT * FROM orders WHERE id BETWEEN 10001 AND 20000，再用这批user_id去IN查用户，注意批次控制在 5000 以内，避免触发max_allowed_packet
临时应急可设 SET SESSION join_buffer_size = 2*1024*1024（2MB），但仅限调试，切勿写进配置文件全局生效。
哪些场景绝对不该碰 join_buffer_size
以下情况调它不仅无效，还会埋雷：
- 服务器总内存 ≤ 4GB：默认 256KB 已足够，设高反而挤占
innodb_buffer_pool_size，导致磁盘 IO 暴增 - 使用连接池（如 HikariCP）且
max_active=100：每个连接都吃一份 buffer，100 × 4MB = 400MB，纯属浪费 - 业务 SQL 大量使用
LEFT JOIN且右表无索引：这时该修 SQL 或建索引，不是调 buffer - MySQL 版本 ≥ 8.0.22：
Hash Join成为默认，join_buffer_size对性能无影响，只占内存
真正要盯的内存大户永远是 innodb_buffer_pool_size 和 tmp_table_size，join_buffer_size 只是边缘参数，动它之前，先确认执行计划里有没有红色的 Using join buffer。
