EXISTS不物化子查询结果，内存恒定；IN必须全量执行并物化子查询结果集，易触发磁盘临时文件或OOM。NOT IN因需处理NULL且强制物化，问题更严重；正确关联条件（如u.id = o.user_id）是EXISTS高效前提。
EXISTS 不物化子查询结果集
IN 必须把子查询全部执行完，把所有结果加载进内存（或 work_mem 中的临时哈希表），才能开始外层匹配。比如 WHERE id IN (SELECT id FROM huge_log WHERE ts > '2026-01-01')，哪怕只用判断“是否在集合里”，PostgreSQL 也得先把几百万行 id 全读出来、去重、建哈希——这一步就可能吃光 work_mem，触发磁盘临时文件，甚至 OOM。
EXISTS 完全跳过这步：它不收集任何值，每次只拿外层一行的字段（如 o.customer_id），代入子查询中做一次索引查找（例如 SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active'）。找到第一条就返回 TRUE，立刻退出；没找到就返回 FALSE。整个过程没有中间结果集，内存占用恒定在几 KB 级别。
EXISTS 的执行计划里看不到 Materialize 节点
你跑 EXPLAIN (ANALYZE, FORMAT JSON) 对比两条语句，会发现 IN 版本大概率出现 "Node Type": "Materialize" 或 "Planning Time" 明显偏高；而 EXISTS 版本更常显示 "Node Type": "Index Scan" 或 "Semi Join"，且 "Actual Total Time" 主要花在外层扫描 + 若干次快速索引探查上。
关键点在于：MATERIALIZE 节点意味着 PostgreSQL 真的把子查询结果存下来了——这是内存消耗的直接证据；而 EXISTS 即使被优化器重写为半连接（Semi Join），也始终是流式驱动，不缓存数据行。
NOT IN 会让内存问题雪上加霜
-
NOT IN不仅要物化子查询结果，还必须额外处理 NULL：只要子查询任意一行的字段为NULL（比如日志表里某条user_id IS NULL），整个条件判为UNKNOWN，结果集为空——这时你查不到数据，但EXPLAIN看不出异常，只会发现rows=0和大量Buffers: shared hit=xxx read=yyy -
NOT EXISTS没这个问题：它不依赖子查询结果值，只看是否存在满足关联条件的行，NULL 值完全不影响布尔判断，也不增加物化开销 - 更隐蔽的是，
NOT IN在物化阶段无法跳过 NULL 行，反而要全扫子查询表来确认有没有 NULL，进一步放大 I/O 和内存压力
容易被忽略的硬性前提：关联条件必须写对
EXISTS 能省内存，前提是子查询里真有有效的关联条件。如果漏写或写错，比如：
WHERE EXISTS (SELECT 1 FROM orders WHERE status = 'shipped')
这就退化成无关联子查询——PostgreSQL 会当成“只要 orders 表里存在任意一条 shipped 订单，就对主表所有行返回 TRUE”，执行计划里变成 Result 节点配 One-Time Filter，看似快，实则逻辑错误；而如果写成：
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'shipped')
才真正触发逐行索引探查，内存可控。所以检查执行计划里的 Index Cond 是否包含外层字段，比死记“EXISTS 更省内存”重要得多。
