嵌套查询内存爆棚的根源是优化器执行时反复扫描、物化中间结果及排序/哈希操作；MySQL 5.7/PG 12前默认nested-loop策略导致主表每行都重执行子查询，几万行即触碰tmp_table_size或work_mem上限，引发断连、卡死或OOM Killer介入。
嵌套查询本身不直接耗内存，真正让数据库撑爆的是优化器执行时反复扫描、物化中间结果、排序或哈希操作——几万行就可能触发 tmp_table_size 或 work_mem 超限，最终断连、卡死或被 OOM Killer 杀掉。
为什么 IN/EXISTS 子查询会反复扫描、撑爆内存
MySQL 5.7、PostgreSQL 12 之前默认用 nested-loop 执行策略：对主表每行都独立执行一次子查询。这不是语法问题，是执行模型缺陷。
- 比如
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active')，orders 有 10 万行，users 表没建status索引 → 真扫 10 万次全表 - 每次扫描哪怕只返回几个
id，MySQL 默认tmp_table_size是 64MB，累积几十次就爆；PostgreSQL 的work_mem若设为 4MB，10 万次 × 每次分配 1KB 结构体，也早超限 - 现象不是明确报 OOM，而是
ERROR 2013 (HY000): Lost connection to MySQL server during query、查询卡死数分钟，或日志里出现Spill to disk
用 JOIN 替代时必须前置过滤，否则更糟
别以为把 IN 改成 INNER JOIN 就安全了——只是把“重复扫描”换成了“结果爆炸”。
- 错误写法：
FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'→ 先全量 JOIN 再过滤，orders 和 users 各 10 万行，中间笛卡尔积就是 100 亿行 - 正确写法：
FROM orders o JOIN (SELECT id FROM users WHERE status = 'active') u ON o.user_id = u.id→ 先筛出几百个id，再 join，内存峰值能压到 50MB 以内 - 必须给
users(status, id)建覆盖索引，否则前置子查询本身又变慢 -
NULL行为不等价：原IN遇到orders.user_id IS NULL会整行跳过；JOIN同样丢弃，但如果业务逻辑显式依赖三值逻辑（比如WHERE NOT (user_id IN ()) OR user_id IS NULL），结果就不一致
大结果集必须分批，不能靠调大内存参数硬扛
当子查询结果稳定在几十万行以上，改写 JOIN 也不够用——中间结果仍可能超限。这时要放弃“一次性查完”的思路。
- 先用
SELECT COUNT(*) FROM users WHERE status = 'active'确认基数 - 用
LIMIT/OFFSET分页拉取 ID：SELECT id FROM users WHERE status = 'active' ORDER BY id LIMIT 500 OFFSET 0，每次只取 500 - 每批 ID 拼进
IN或临时表做关联，避免单次内存压力集中 - 别依赖
EXISTS的“短路”特性：现代优化器大多会重写，实际执行计划未必真短路；不如老老实实建好logs(order_id)索引，让JOIN走ref
调参前先确认 tmp_table_size 真被用上了
Using temporary 不是错误，而是 MySQL 因无法用索引直接完成排序或分组而创建临时表；真正影响性能的是是否落盘，由 tmp_table_size 与 max_heap_table_size 中较小值决定。
- 查执行计划：
EXPLAIN FORMAT=tree（MySQL 8.0+）或EXPLAIN，重点看最外层或子查询节点的Extra列是否含Using temporary - 若只在子查询行出现
Using temporary，说明物化发生在内层，且其结果要参与后续操作——这时才受tmp_table_size约束 - 必须同步设置：
tmp_table_size = 256M且max_heap_table_size = 256M；线上常见配置是前者设成 256M，后者仍为默认 16M，结果还是卡死在 16M - 验证是否生效：
SHOW VARIABLES LIKE 'tmp_table_size'; SHOW VARIABLES LIKE 'max_heap_table_size';，两个值必须完全一致
最易被忽略的一点：临时表是“不得已的补救”，不是设计目标。嵌套查询内存高，根因往往不在括号本身，而在数据访问路径没对齐——比如该走索引却做了函数计算、该提前过滤却拖到外层、该用键集分页却硬扛 OFFSET。改写时优先砍中间结果，其次才是调参。
