嵌套子查询是否真慢需先看执行计划：若子查询节点Actual Total Time超60%且Rows少，可能是相关子查询反复执行；若Rows Removed by Filter远大于Rows，则缺索引或条件未下推；InitPlan只执行一次，SubPlan每行都执行。
怎么看嵌套子查询是不是真慢了
别急着重写 SQL，先确认瓶颈确实在子查询本身。很多情况下 EXPLAIN ANALYZE 显示的“慢”，其实是外层 JOIN 或排序拖累的，子查询只是被连带曝光了。
关键看执行计划里子查询对应节点的 Actual Total Time 和 Rows Removed by Filter：
- 如果子查询节点的
Actual Total Time占整条语句 60% 以上，且Rows很小（比如只返回几行），但耗时高 → 很可能在反复执行（correlated subquery） - 如果
Rows Removed by Filter远大于Rows（比如扫描 10 万行只留 3 行）→ 子查询缺少有效索引或条件没下推 - 注意
Subplan Name是InitPlan还是SubPlan：前者通常只执行一次，后者在每行外层数据上都执行一遍
把 correlated subquery 改成 JOIN 为什么常能提速
PostgreSQL 对 WHERE x IN (SELECT y FROM t WHERE t.a = outer.b) 这类相关子查询，往往无法自动重写为高效 JOIN，尤其当子查询含聚合、DISTINCT 或 LIMIT 时。
手动改写的核心逻辑是：把子查询“拉平”成派生表，用 ON 条件对齐关联字段，再用 LEFT JOIN ... ON ... AND ... 保留语义。
- 原写法：
SELECT * FROM orders o WHERE o.customer_id IN (SELECT id FROM customers c WHERE c.status = 'active') - 改写后：
SELECT o.* FROM orders o JOIN customers c ON o.customer_id = c.id AND c.status = 'active' - 若原意是“订单存在活跃客户”，用
JOIN更准；若是“订单客户状态为活跃”，且要保留无匹配的订单，就得用LEFT JOIN+WHERE c.id IS NOT NULL - 注意：
IN自动去重，JOIN可能放大行数（如一个 customer_id 对应多条 customers 记录），必要时加DISTINCT或用EXISTS
EXISTS 比 IN 快，但不是所有场景都适用
EXISTS 能短路（找到第一行就停），IN 在子查询结果集小时也快，但一旦子查询返回 NULL，IN 整体结果就变 UNKNOWN —— 这是业务逻辑静默崩坏的高发点。
- 当子查询可能返回
NULL（比如SELECT nullable_col FROM t），IN会跳过整行匹配 → 用EXISTS更安全 -
EXISTS不关心子查询 SELECT 列内容，写SELECT 1或SELECT NULL都行，优化器不解析字段列表 - 但
EXISTS无法直接替代IN做多列匹配（如(a,b) IN (SELECT x,y FROM t)），此时得用ROW(a,b) IN (SELECT ROW(x,y) FROM t)或改写为 JOIN - 某些旧版 PostgreSQL（LIMIT 的
EXISTS子查询优化不佳，需加OFFSET 0强制物化
临时表 or CTE？别无脑选 CTE
很多人看到子查询复杂，第一反应是塞进 WITH，但 PostgreSQL 12+ 之前，CTE 默认强制物化（materialize），哪怕只用一次，也会多一次写临时磁盘的开销。
- 如果子查询被外层多次引用（如在 SELECT 和 WHERE 都用到），且结果集不大（WITH 可避免重复计算
- 如果子查询只用一次，且本身带聚合或排序，优先考虑内联（inline）或创建带索引的临时表：
CREATE TEMP TABLE tmp_foo AS SELECT ...; CREATE INDEX ON tmp_foo(col); - 临时表可显式
ANALYZE tmp_foo，让优化器拿到准确统计信息；CTE 的统计信息始终是估算的 - 注意：临时表在事务结束后自动销毁，但长事务中堆积太多会影响
pg_temp目录空间
最常被忽略的一点：嵌套子查询的性能问题，80% 出现在没有给子查询里的 WHERE 条件字段建索引，而不是写法本身。先跑一遍 EXPLAIN (ANALYZE, BUFFERS)，盯住 Seq Scan 行，再决定要不要动 SQL 结构。
