筛选表1部分数据存入临时表后关联表2，能否提升PostgreSQL查询速度？

先说结论：先筛选表1的39k行存入临时表，再与表2关联，大概率能显著提升查询速度。下面分几个点给你详细拆解：

一、临时表优化为什么有效？ #

• 数据量级大幅降低：原本左连接要处理表1的5000万行+表2的1亿行，临时表方案先把表1缩小到39k行，后续连接的计算量、IO开销直接砍了几个数量级，效率提升非常明显。
• 更精准的执行计划：39k行属于典型小表，PostgreSQL优化器会针对它生成更高效的连接策略（比如嵌套循环或哈希连接，而非大表常用的合并连接）。如果需要，你还能给临时表的关联字段甚至筛选字段建索引，进一步加速后续操作。

二、PostgreSQL会自动做类似优化吗？ #

PostgreSQL的查询优化器确实会尝试过滤条件下推——也就是先执行表1的WHERE筛选，再做左连接，但这个优化有不少限制，不一定总能按预期生效：

• 统计信息过时：如果表1的统计信息没更新，优化器可能不知道你的WHERE条件只会筛出39k行，反而选错“先连接再过滤”的低效计划。
• 复杂过滤逻辑：如果WHERE子句包含复杂函数、子查询，或者非SARGable条件（比如LIKE '%xxx'），优化器可能无法正确判断过滤后的数据集大小，也没法把过滤条件下推到连接之前。
• 无索引的筛选字段：就算优化器想先筛选，若WHERE字段没索引，表1的全表扫描（5000万行）本身就很慢，这时候手动提前筛选存入临时表，相当于把最耗时的步骤先做完，后续连接会快很多。

三、额外的优化建议 #

• 优先给WHERE筛选字段建索引：这是最基础的优化！如果筛选表1的条件字段没有索引，先给这些字段建B-tree索引（等值查询场景），不管用不用临时表，都能大幅加快39k行的筛选速度。
• 临时表索引可选：39k行的小表和表2关联时，PostgreSQL大概率会自动用哈希连接或嵌套循环（不用索引也很快），但如果表2的关联字段索引性能一般，给临时表的关联字段建个索引也能锦上添花。
• 示例代码参考：
  原慢查询：

  SELECT *
  FROM table1 t1
  LEFT JOIN table2 t2 ON t1.关联字段 = t2.关联字段
  WHERE t1.筛选字段 = '目标值'; -- 筛选出39k行，但筛选字段无索引
  

  优化后的临时表方案：

  -- 创建临时表并筛选数据（若筛选慢，先给筛选字段建索引）
  CREATE TEMP TABLE filtered_t1 AS
  SELECT * FROM table1 WHERE 筛选字段 = '目标值';
  
  -- 可选：给临时表的关联字段建索引
  CREATE INDEX idx_filtered_t1_join_col ON filtered_t1(关联字段);
  
  -- 执行连接查询
  SELECT *
  FROM filtered_t1 t1
  LEFT JOIN table2 t2 ON t1.关联字段 = t2.关联字段;
  

内容的提问来源于stack exchange，提问作者Michael Curtis