PostgreSQL为何会在顺序扫描与索引扫描之间切换查询计划？

这个情况其实是PostgreSQL查询优化器（Query Planner）的典型动态决策行为——它每次执行查询时，都会基于当前的统计数据、数据分布和成本预估，选择它认为最高效的执行路径。结合你的场景，具体原因可以从这几个角度分析：

1. 统计信息不准导致的预估偏差 #

PostgreSQL的优化器完全依赖pg_statistic系统表中的统计数据来估算查询匹配的行数。看你的执行计划：

索引扫描计划：预估rows=1，实际返回1000行
顺序扫描计划：预估rows=1，实际同样返回1000行

这说明统计信息已经过时或者不准确了——优化器误以为符合条件的数据极少，所以尝试用索引扫描；但当实际匹配的数据量占比不低时（你的表总共有3000行，匹配1000行，占比33%），优化器可能又会认为顺序扫描的整体开销更低，从而切换执行计划。

2. 不稳定函数导致计划无法缓存 #

你的查询里用到了CURRENT_TIMESTAMP，这属于PostgreSQL的不稳定函数（结果每次执行都可能变化）。对于包含这类函数的查询，PostgreSQL不会缓存执行计划，每次执行都会重新生成计划。这就意味着每次执行时，优化器都会重新评估两种扫描方式的成本，而如果统计信息本身有偏差，就容易出现不同的选择结果。

3. 扫描方式的成本阈值切换 #

PostgreSQL的优化器会计算两种扫描的成本：

• 顺序扫描：主要是全表读取的IO开销，适合匹配数据量较大的场景（通常当匹配数据占表总量的10%-20%以上时，全表扫描的开销可能低于索引+回表的总开销）。
• 索引扫描：需要先遍历索引找到匹配条目，再回表获取数据，适合匹配数据量较小的场景。

你的场景中，匹配数据占比刚好在优化器的决策阈值附近（33%），所以当优化器的成本预估出现微小偏差时，就会在两种扫描方式之间切换。

解决建议 #

• 更新统计信息：先执行ANALYZE test;，让优化器获取最新的表数据分布，这样它的行数预估会更准确，执行计划也会更稳定。
• 创建覆盖索引：如果你的查询只需要id字段，可以把索引改成包含id的覆盖索引，避免回表开销：

  CREATE INDEX IF NOT EXISTS start_month_id_idx 
  ON test (date_part('month',(start_date AT TIME ZONE 'UTC'))) 
  INCLUDE (id);
  

  这样索引扫描的成本会大幅降低，优化器会更倾向于选择索引。
• 避免强制索引：除非万不得已，不建议用INDEX强制指定索引——优化器的动态决策通常更贴合实际数据情况，优先保证统计信息准确才是根本。

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