IN子查询返回几万行易致内存溢出，因数据库默认物化全部结果做哈希匹配或嵌套循环，突破tmp_table_size（MySQL默认64MB）或work_mem（PostgreSQL默认4MB），引发OOM；应优先用带索引的JOIN、EXISTS或分批ID拉取替代。
IN 子查询返回几万行就可能触发内存溢出，不是语法错，而是数据库默认把整个子结果物化进内存做哈希匹配或嵌套循环——tmp_table_size 和 work_mem 同时被突破，连接直接断开或进程被 OOM Killer 杀掉。
为什么 IN (SELECT ...) 会爆内存
MySQL 和 PostgreSQL 在优化器未启用物化或半连接时，会为外层表每一行重复执行子查询（nested-loop），哪怕子查询只返回 ID 列。10 万行主表 × 每次扫描子表 → 中间结果累积撑爆内存。
-
EXPLAIN看到Using temporary; Using filesort或Materialize节点，基本就是内存压力源头 - MySQL 默认
tmp_table_size = 64M，PostgreSQL 默认work_mem = 4MB，两者都以较小值为准生效 - 子查询没索引（比如
WHERE status = 'active'但users(status)缺失），全表扫 + 重复执行，雪上加霜
用 JOIN 替代时必须前置过滤
直接写 FROM t1 JOIN t2 ON t1.id = t2.ref_id WHERE t2.status = 'X' 是危险的：先笛卡尔积再过滤，中间结果可能达亿级。
- 正确写法是
FROM t1 JOIN (SELECT id FROM t2 WHERE status = 'X') AS t2 ON t1.ref_id = t2.id，确保子查询先走索引筛出几百/几千行 -
t2(status, id)必须建覆盖索引，否则子查询本身又变慢，还可能回表生成更大中间集 - 注意 NULL 行行为：
IN自动跳过t1.ref_id IS NULL，JOIN同样丢弃；但若业务依赖NOT IN的三值逻辑，改写后结果不等价
EXISTS 比 IN 更省内存，但写法有陷阱
EXISTS 不物化子结果，靠关联条件尽早退出，但前提是子查询带有效关联和索引支持。
- 写成
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')才有效；user_id必须是orders的索引前缀字段 - 禁止写无关联的
EXISTS (SELECT 1 FROM orders)，它会被当恒真处理，反而强制物化 - PostgreSQL 中
EXISTS默认走 nested-loop，若u.id不是主键或没索引，照样扫全表 —— 先EXPLAIN验证执行计划
分批拉取 ID 是最稳的兜底方案
当子查询稳定返回 >5 万行，且无法加有效过滤条件时，硬调 tmp_table_size 或 work_mem 只会放大并发风险，不如拆成小批次。
- 先查总数：
SELECT COUNT(*) FROM t2 WHERE ...，确认是否真要全量 - 每次取 500–5000 行 ID：
SELECT id FROM t2 WHERE ... ORDER BY id LIMIT 500 OFFSET 0，必须ORDER BY+ 索引，否则OFFSET越往后越慢 - 拼进主查询：
WHERE id IN (1,2,...,500)，注意 MySQLmax_allowed_packet限制实际参数长度 - ID 连续且有索引时，优先用范围替代
IN：WHERE id BETWEEN ? AND ?，避免参数膨胀
defaultFetchSize=500）+ 游标分页比任何服务端改写都更轻量、更可控。 
