PostgreSQL中先过滤后关联与先关联后过滤性能是否等价？

直接给结论：PostgreSQL 12及以上版本默认情况下，两种写法性能几乎一致；但12之前的版本，Option 2可能出现明显性能问题，具体原因如下：

1. 查询优化器的自动调整能力 #

PostgreSQL的查询优化器（Planner）不会死板遵循SQL的书写顺序执行，它会自动重写查询逻辑，把过滤条件尽可能下推到基表阶段。比如Option 2里的where id1 = 1，优化器会识别出这个条件可以直接作用于table1和table2，最终执行逻辑和Option 1的「先过滤再关联」完全一致。

只要你的id字段有合适的索引，两种写法都会优先走索引扫描，快速过滤出少量符合条件的数据后再关联，性能没有差异。

2. CTE的版本差异（核心影响点） #

PostgreSQL 12之前，CTE（WITH子句）是优化栅栏——优化器不会将CTE内的逻辑内联到主查询中。这意味着Option 2会真的先把table1和table2全表关联，生成一个巨大的中间结果集后再过滤，大表场景下性能会暴跌。

而PostgreSQL 12及以后，默认开启了CTE内联优化，除非显式使用MATERIALIZED关键字强制物化CTE，否则优化器会将Option 2的CTE逻辑展开，和Option 1的执行路径完全相同。

3. 视图组织DRY代码的影响 #

如果用视图实现DRY（Don't Repeat Yourself），逻辑和CTE类似：

• 普通视图默认会被优化器展开，优化器会重新调整过滤和关联顺序，不会因为视图里写的是「先关联再过滤」就真的执行全表关联。
• 若使用MATERIALIZED（物化视图），视图会预先存储关联后的结果，此时如果过滤条件是物化后添加的，性能会变差——但这是物化视图的特性，和普通视图无关。

验证方法 #

要确认两种写法的性能是否一致，直接用EXPLAIN ANALYZE查看执行计划：

-- 查看Option1的执行计划
EXPLAIN ANALYZE
with filteredTable1 as 
    (select *
    from table1
    where table1.id = 1),
   filteredTable2 as
   (select *
    from table2
    where table2.id = 1) 
select * 
from filteredTable1
inner join filteredTable2 on filteredTable1.id = filteredTable2.id;

-- 查看Option2的执行计划
EXPLAIN ANALYZE
with joinedTables as
    (select *
     from table1
     inner join table2 on table1.id = table2.id)
select *
from joinedTables
where id1 = 1;

如果两个查询的执行计划显示的扫描方式（如Index Scan using idx_table1_id on table1）、关联类型、行数估计和实际执行时间基本一致，说明性能完全相同。

内容的提问来源于stack exchange，提问作者Brandon Peck