Postgres如何强制重新生成执行计划让查询使用新建覆盖索引

问题核心原因 #

PostgreSQL仅对通过PREPARE创建的预备语句，才会在1~5次执行后固化通用执行计划，普通即席查询每次执行都会重新生成计划。你遇到的不走新索引的问题，要么是当前会话缓存了旧的预备语句执行计划，要么是优化器计算得出旧索引ix_1的成本更低。

方案1：清空会话执行计划缓存 #

如果是长连接/连接池会话缓存了旧计划，直接在当前会话执行DISCARD PLANS;即可清空所有缓存的执行计划，下次执行查询时会重新生成，自动纳入新索引ix_2的成本计算。如果是简单场景，直接断开当前会话重连也可以达到同样效果。

方案2：调整优化器成本参数引导索引选择 #

如果清空缓存后仍然不走ix_2，说明优化器对覆盖索引的成本计算更优，可以在会话级别临时调整以下参数测试：

• 降低random_page_cost：默认值为4，如果你使用SSD存储，可以调整到1.0~1.5之间，降低优化器对随机IO的成本预估，更倾向于使用不需要回表的覆盖索引
• 降低cpu_index_tuple_cost：默认值为0.005，适当下调可以减少索引扫描的CPU成本预估

测试语句如下：

SET random_page_cost = 1.1;
SET cpu_index_tuple_cost = 0.001;
-- 查看执行计划是否使用ix_2
EXPLAIN ANALYZE
select col1, col2 
from table_a
where col1='a'
and col3='b'
order by col1 desc
limit 5;

如果测试符合预期，可以将参数调整为全局配置，或者仅在执行该查询的会话中单独设置。

方案3：绕过旧计划缓存匹配 #

如果是框架自动生成的预备语句无法修改配置，可以轻微调整查询语句的结构，让优化器认为这是一条全新的查询，跳过旧的缓存计划匹配，例如新增一个无业务影响的恒真条件：

select col1, col2 
from table_a
where col1='a'
and col3='b'
and 1=1 -- 新增恒真条件，触发新计划生成
order by col1 desc
limit 5;

方案4：临时移除旧索引（可选） #

如果确认旧索引ix_1没有其他业务查询依赖，ix_2的前缀(col1 desc, col3)已经完全覆盖ix_1的所有使用场景，可以先删除ix_1，等查询稳定走ix_2之后如有需要再重建ix_1即可，注意十亿级大表重建索引会占用大量IO并加共享锁，需要在业务低峰期操作。

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