嵌套查询易爆内存因外层每行触发内层重复执行，无索引时致海量全表扫描与临时表膨胀；应改用带前置过滤和索引的JOIN，并验证执行计划、结果行数及字段类型一致性。
为什么嵌套查询会爆内存
因为数据库执行 IN 或 EXISTS 子查询时，常会为每条外层记录重复执行内层逻辑；如果外层有 10 万行，内层表又没索引，就可能触发 10 万次全表扫描+临时结果集累积。MySQL 默认的 tmp_table_size 和 max_heap_table_size 压不住这种膨胀，直接报 Out of memory 或卡死。
常见错误现象：ERROR 2013 (HY000): Lost connection to MySQL server during query、Query execution was interrupted、或者慢得像挂了但没报错。
适用场景：你正在写类似 SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active') 这种语句，且 users 表数据量超 10 万行。
用 INNER JOIN 替代 IN 子查询的实操要点
核心不是“换语法”，而是控制连接基数和提前过滤。JOIN 本身不保证性能，但给了你显式控制中间结果大小的机会。
- 必须给被驱动表（通常是子查询里的那张）加索引：比如
users(status, id)覆盖索引，避免回表 - 把过滤条件尽量往前压：不要写
SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'，而要写SELECT * FROM orders o JOIN (SELECT id FROM users WHERE status = 'active') u ON o.user_id = u.id—— 这样先筛出几千个id，再 join，比全量 join 后 where 筛快得多 - 注意 NULL：如果
orders.user_id可能为NULL，而users.id是主键，JOIN 自然排除掉这些行；但原IN子查询遇到NULL会整个返回空结果集（三值逻辑），行为不等价，需确认业务是否允许丢弃
EXISTS 改 LEFT JOIN + IS NOT NULL 的注意事项
很多人直接把 WHERE EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id) 换成 LEFT JOIN logs l ON l.order_id = o.id WHERE l.order_id IS NOT NULL，看起来一样，其实有坑：
- 如果
logs表里一个order_id对应多条日志，LEFT JOIN 会产生笛卡尔积，导致外层记录重复——原 EXISTS 不会 - 解决办法只有两个：
DISTINCT（代价高），或改用INNER JOIN（更准确，也更高效） - 别依赖
EXISTS的“短路”特性：现代优化器大多会重写，实际执行计划未必真短路；不如老老实实建好logs(order_id)索引，让 JOIN 走 ref
改写后还要验证的三个地方
光改 SQL 不够，容易上线翻车：
- 检查执行计划：用
EXPLAIN FORMAT=TRADITIONAL看是否走了索引，rows是否明显下降，有没有出现Using temporary; Using filesort - 核对结果行数：特别是涉及
GROUP BY或聚合时，JOIN 可能因一对多放大行数，而原嵌套查询不会——这时候得加GROUP BY或用SELECT DISTINCT - 留意事务隔离级别：如果原嵌套查询在 RR 级别下用了 MVCC 快照，而新 JOIN 在 RC 下跑，可能读到不一致的中间状态，尤其在高并发更新场景
最麻烦的其实是关联字段类型不一致：比如 orders.user_id 是 BIGINT，users.id 是 INT，MySQL 会隐式转换，导致索引失效——这种细节一漏，前面所有优化都白搭。
