mysql 8.0中join内存溢出90%以上主因是被驱动表缺索引导致全表扫描，而非join_buffer_size过小；应先用explain确认是否真用block nested-loop，再优先加索引、其次分批查，调参数反而加速oom。
MySQL 8.0 中 JOIN 导致内存溢出，90% 以上不是因为 join_buffer_size 太小，而是被驱动表缺索引触发全表扫描，把几百万行硬塞进内存缓冲区。调大参数反而加速 OOM。
查执行计划确认是否真在用 Block Nested-Loop
先运行 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE，看输出里有没有 Using join buffer (Block Nested Loop)。没有就别碰 join_buffer_size——MySQL 8.0.22+ 默认禁用 BNL，改用 Hash Join，此时该参数完全不生效。
- 有这个提示：说明被驱动表关联字段（如
ON t1.a = t2.b中的t2.b）没索引，正在全表扫描 - 没这个提示但仍有内存暴涨：重点查
Created_tmp_disk_tables和Sort_merge_passes，可能是ORDER BY或GROUP BY触发磁盘临时表 -
EXPLAIN显示type=ALL或Extra含Using temporary; Using filesort：索引缺失或覆盖不全
加索引比调 join_buffer_size 有效 10 倍
被驱动表的 ON 字段必须有索引，且最好是主键或唯一索引。例如 JOIN orders o ON u.id = o.user_id，orders.user_id 必须建索引；如果还查 o.amount，考虑建联合索引 INDEX idx_user_id_amount (user_id, amount) 避免回表。
- 不要只给驱动表加索引——驱动表走索引是默认行为，关键在被驱动表
- 复合条件如
WHERE status = 1 AND user_id IN (...)，索引要按status, user_id顺序建，否则user_id用不上 - 用
ANALYZE TABLE更新统计信息，避免优化器误判驱动表大小
分批查 + 应用层合并是最后防线
当无法加索引（比如日志表、历史归档表），或单次 JOIN 返回结果超 50 万行时，放弃 SQL 层 JOIN，改用主键范围分片 + 精准 IN 查询。
- 左表必须有自增主键（如
id BIGINT PRIMARY KEY），才能安全分段：WHERE id BETWEEN 10001 AND 20000 - 右表关联字段必须有索引，否则每次
IN都变全表扫描 - 批次大小控制在 5000–10000，避免触发
max_allowed_packet；Java 用PreparedStatement批量绑定，Python 用executemany() - MySQL 8.0+ 可建临时表存 ID：
CREATE TEMPORARY TABLE tmp_ids(id BIGINT); INSERT INTO tmp_ids VALUES (1),(2),...; SELECT ... JOIN tmp_ids ON ...
哪些操作会雪上加霜
以下配置或写法会让内存问题更隐蔽、更难排查：
- 全局设
SET GLOBAL join_buffer_size = 4*1024*1024：每个连接独占，max_connections=200就吃掉 800MB，挤占innodb_buffer_pool_size，IO 直接拉满 - 在应用层拼超长
IN (1,2,3,...,20000)字符串：不仅可能超max_allowed_packet，还会让 MySQL 放弃使用索引，退化成全表扫描 - 用子查询“伪装”分批，如
SELECT * FROM t1 JOIN (SELECT id FROM t2 WHERE ... LIMIT 1000) AS t2 ON ...：优化器仍可能把整个t2加载进内存再截断 - 服务器总内存 ≤ 4GB 还设
join_buffer_size > 256KB：默认值已足够，调高只会抢走 InnoDB 缓冲池内存，得不偿失
真正卡住的地方往往不是 JOIN 本身，而是被驱动表那条没建索引的 ON 字段——它让 MySQL 别无选择，只能把整张表往内存里拖。查 EXPLAIN、加索引、分批次，这三步走完，95% 的内存溢出就消失了。剩下 5%，得看是不是在用 TEXT 字段做 JOIN，或者有没有人把 20 张表连在一起写了个巨长的视图。
