PostgreSQL在查询重写阶段会自动将符合条件的子查询转为JOIN以提升性能。主要场景包括：标量子查询出现在SELECT列表且保证单行结果时可转为LEFT JOIN；EXISTS或IN的相关子查询通常转为SEMI JOIN；FROM中的非相关派生表可合并优化；可去关联化的相关子查询在语义允许时也会转换。重写机制发生在语法分析后、规划前，核心是视图展开和子查询去关联化，例如EXISTS子查询会被改写为Hash Semi Join。但若子查询含聚合无GROUP BY、使用LIMIT/OFFSET、含UNION等复杂操作，或存在无法解析的关联表达式，则可能阻碍转换。通过EXPLAIN可观察执行计划中是否出现相应JOIN类型，结合debug_query_rewrite参数可查看重写后的查询树。该过程基于语义正确性与优化可行性自动完成，理解其原理有助于编写更高效的SQL语句。
PostgreSQL 在执行查询时，会通过查询重写系统对原始 SQL 进行逻辑等价变换，其中子查询转为 JOIN 是常见且关键的优化手段。这种转换能提升执行效率，因为 JOIN 通常比嵌套子查询更容易被优化器生成高效执行计划。
何时子查询会被转为 JOIN
PostgreSQL 并非对所有子查询都进行转换，只有满足特定条件的子查询才会在查询重写阶段被自动转为 JOIN。主要场景包括：
-
标量子查询出现在 SELECT 列表中：如果子查询返回单行单列，并且关联到外层查询（即相关子查询），且保证最多一行，PostgreSQL 可将其改写为
LEFT JOIN，避免重复执行。 -
EXISTS 或 IN 的相关子查询：当使用
EXISTS(SELECT ... WHERE outer.col = inner.col)或col IN (SELECT ...)，且子查询是相关联的，优化器通常会将其转为SEMI JOIN，这本质上是一种逻辑上的JOIN形式。 -
FROM 中的派生表（非相关子查询）：若子查询位于
FROM子句中（即内联视图），且不依赖外层查询，PostgreSQL 会直接将其与外层查询合并处理，可能与其他表做JOIN，并参与整体的连接顺序优化。 -
可去关联化的相关子查询：PostgreSQL 查询重写器会尝试“去关联化”（unnesting），将相关子查询转化为
JOIN，前提是语义允许，例如聚合函数不会改变基数。
查询重写的关键机制
PostgreSQL 的查询重写发生在语法分析之后、查询规划之前，由重写规则系统（rewrite system）完成。其核心行为包括：
- 视图展开：如果查询涉及视图，系统会把视图定义中的子查询展开到主查询中，形成一个扁平化的查询结构，便于后续优化。
-
规则应用：用户自定义的
CREATE RULE也可能触发重写，但优化相关的重写主要由内部逻辑驱动。 -
子查询去关联化：这是最关键的一步。PostgreSQL 会分析子查询是否依赖外层变量，若依赖但可安全展开，则引入
JOIN来替代循环执行子查询。
例如，以下查询：
SELECT name FROM employees e WHERE EXISTS (SELECT 1 FROM departments d WHERE d.id = e.dept_id AND d.active);通常会被重写为：
SELECT DISTINCT e.name FROM employees e JOIN departments d ON d.id = e.dept_id WHERE d.active;实际执行计划中表现为 Hash Semi Join，效率远高于逐行执行子查询。
影响重写的因素
并非所有子查询都能被成功转为 JOIN，以下情况可能阻碍重写：
-
子查询包含聚合且无 GROUP BY：如
SELECT (SELECT AVG(salary) FROM emp)，这类标量子查询虽可能保留为子链接（sublink），但不会转为JOIN。 -
使用了 LIMIT 或不支持的运算符：某些带
LIMIT、OFFSET或集合操作（如UNION）的子查询难以等价转换。 -
存在不可去关联的表达式：比如子查询中引用了外层多个表或复杂表达式，导致无法构建等效
JOIN条件。
如何查看重写结果
可通过 EXPLAIN 查看执行计划，判断是否发生 JOIN 转换：
若输出中出现 Hash Semi Join 或 Nested Loop 配合子查询消失，说明已重写。更深入可使用 debug_query_rewrite 参数打印重写后的查询树：
基本上就这些。PostgreSQL 的子查询转 JOIN 是自动且智能的过程，依赖语义正确性和优化可行性。理解这一机制有助于写出更易优化的 SQL。
