没索引触发OOM是因为MySQL启用BNL算法时将驱动表全量缓存至join_buffer，若驱动表50万行×2KB/行=1GB，5并发即超限；EXPLAIN中type=ALL且Extra含Using join buffer即为危险信号。
JOIN没索引为什么会触发OOM
不是JOIN本身吃内存，而是MySQL被迫启用Block Nested-Loop Join（BNL）算法时，把驱动表结果集全量缓存进join_buffer，再批量去扫被驱动表——如果驱动表有50万行、每行平均2KB，光buffer就要1GB；若并发5个这样的查询，直接打爆默认的join_buffer_size（通常256KB~4MB），挤占其他连接内存，最终触发OOM。
EXPLAIN里看到type=ALL就危险了
只要被驱动表的ON字段没索引，EXPLAIN的type列就会是ALL或index，同时Extra列出现Using join buffer (Block Nested Loop)。这时MySQL已放弃索引查找，转为缓冲+全表扫描模式。
- 哪怕被驱动表只有10万行，BNL也会反复读它，IO放大严重，buffer持续膨胀
-
join_buffer是会话级分配的，不会自动释放，直到语句结束 - 线上高并发下，多个
ALLJOIN叠加，内存占用呈线性甚至指数增长
别信“调大join_buffer_size能解决问题”
增大join_buffer_size只是让单次查询撑得更久，不解决根本问题：
- buffer越大，一次批量扫描的被驱动表数据越多，随机IO越密集，磁盘I/O反而更卡
- 全局调大该值，会抢占
sort_buffer_size、read_buffer_size等关键内存，其他查询也变慢 - 真正该做的：给被驱动表的
ON字段建索引，让执行计划从ALL变成ref或eq_ref - 建索引前先用
SHOW CREATE TABLE核对两表字段类型是否严格一致（INT vs VARCHAR、长度、NULL约束），否则隐式转换照样让索引失效
临时救急但不能长期依赖的方案
当无法立刻加索引（比如权限受限、表太大锁不住），可考虑：
- 用
STRAIGHT_JOIN强制小表作驱动表，缩小join_buffer输入规模 - 把大表先
CREATE TEMPORARY TABLE SELECT ... WHERE过滤出子集，再对临时表建索引 - 在应用层分页+多次JOIN，用
LIMIT控制每次驱动表结果集大小
这些只是过渡手段。只要被驱动表的关联字段没索引，BNL就随时可能把内存耗尽——这不是配置问题，是数据访问路径的根本缺陷。
