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 通常比嵌套子查询更容易被优化器生成高效执行计划。
PostgreSQL 并非对所有子查询都进行转换，只有满足特定条件的子查询才会在查询重写阶段被自动转为 JOIN。主要场景包括：
在语义允许时也会转换。重写机制发生在语法分析后、规划前，核心是视图展开和子查询去关联化，例如EXISTS子查询会被改写为Hash Semi Join。但若子查询含聚合无GROUP BY、使用LIMIT/OFFSET、含UNION等复杂操作，或存在无法解析的关联表达式，则可能阻碍转换。通过EXPLAIN可观察执行计划中是否出现相应JOIN类型，结合debug_query_rewrite参数可查看重写后的查询树。该过程基于语义正确性与优化可行性自动完成，理解其原理有助于编写更高效的SQL语句。LEFT JOIN，避免重复执行。EXISTS(SELECT ... WHERE outer.col = inner.col) 或 col IN (SELECT ...)，且子查询是相关联的，优化器通常会将其转为 SEMI JOIN，这本质上是一种逻辑上的 JOIN 形式。FROM 子句中（即内联视图），且不依赖外层查询，PostgreSQL 会直接将其与外层查询合并处理，可能与其他表做 JOIN，并参与整体的连接顺序优化。JOIN，前提是语义允许，例如聚合函数不会改变基数。PostgreSQL 的查询重写发生在语法分析之后、查询规划之前，由重写规则系统（rewrite system）完成。其核心行为包括：
CREATE RULE 也可能触发重写，但优化相关的重写主要由内部逻辑驱动。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，以下情况可能阻碍重写：
SELECT (SELECT AVG(salary) FROM emp)，这类标量子查询虽可能保留为子链接（sublink），但不会转为 JOIN。LIMIT、OFFSET 或集合操作（如 UNION）的子查询难以等价转换。JOIN 条件。可通过 EXPLAIN 查看执行计划，判断是否发生 JOIN 转换：
若输出中出现 Hash Semi Join 或 Nested Loop 配合子查询消失，说明已重写。更深入可使用 debug_query_rewrite 参数打印重写后的查询树：
基本上就这些。PostgreSQL 的子查询转 JOIN 是自动且智能的过程，依赖语义正确性和优化可行性。理解这一机制有助于写出更易优化的 SQL。