嵌套查询因执行模型缺陷导致重复执行，非语法错误而是优化器采用nested-loop策略所致；应改用前置过滤的JOIN、覆盖索引、分批处理及临时表等方案优化。
嵌套查询会触发重复执行，不是语法问题而是执行模型缺陷
数据库优化器对 IN 或 EXISTS 子查询的默认处理方式，是为外层每一行独立执行一次内层逻辑。这不是你写错了 SQL，而是 MySQL 5.7、PostgreSQL 12 之前普遍采用的 nested-loop 执行策略。
常见错误现象包括：ERROR 2013 (HY000): Lost connection to MySQL server during query、查询卡死数分钟无响应、PostgreSQL 日志里出现 Spill to disk。
- 如果
orders表有 10 万行，users表没建status索引，就会真实发生 10 万次全表扫描 - 每次扫描都可能生成临时结果集（哪怕只返回几个
id），MySQL 默认tmp_table_size是 64MB，几十次就超限 - PostgreSQL 的
work_mem若设为 4MB，10 万次 × 每次分配 1KB 结构体，也早超限
改用 JOIN 不等于自动安全，前置过滤才是关键
很多人把 WHERE user_id IN (SELECT id FROM users WHERE status = 'active') 直接改成 JOIN users u ON o.user_id = u.id WHERE u.status = 'active'，结果更糟——这等于先做全量笛卡尔积再过滤。
orders 和 users 各 10 万行，中间结果就是 100 亿行，内存直接爆。
- 正确写法必须前置子查询：
FROM orders o JOIN (SELECT id FROM users WHERE status = 'active') u ON o.user_id = u.id - 确保
users(status, id)有覆盖索引，避免回表拖慢并延长内存驻留时间 -
NULL行为不等价：原IN遇到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 5000 OFFSET 0 - 每批拿到 ID 后执行主查询：
SELECT * FROM orders WHERE user_id IN (1,2,3,...,5000)，注意别超max_allowed_packet - ID 是连续整型且有索引时，可用范围替代：
WHERE user_id BETWEEN ? AND ?
深层嵌套还可能触发栈溢出，和内存溢出不是一回事
堆栈溢出（StackOverflowError）不是数据量问题，而是调用深度失控。MySQL 多层 JOIN 或存储过程递归，在解析阶段就可能耗尽线程栈空间。
- 检查当前限制：
SHOW VARIABLES LIKE 'thread_stack'，云环境常只有 192KB - 确认是否真由嵌套引起：把
SELECT *换成SELECT 1再跑，如果成功，基本锁定是解析阶段崩了 - 避免单语句混用
WITH、多层JOIN、UNION ALL和标量子查询——它们会叠加解析深度 - 改用临时表分步写入：
CREATE TEMPORARY TABLE tmp_users AS SELECT id FROM users WHERE status = 'active'，再逐层JOIN，每步加索引
真正容易被忽略的是：嵌套查询本身不申请内存，但它会让优化器彻底失去基数感知能力，导致 granted_memory_kb 飙升到实际需要的百倍——你看到的 OOM，往往不是数据太大，而是数据库“算错了”。
