在日常使用PostgreSQL的过程中，不少开发者会发现明明建了索引，查询语句也不复杂，但执行速度就是达不到预期，这时候很大可能是查询计划出现了问题。查询计划是数据库优化器根据表结构、数据分布、系统配置等信息生成的执行路径，如果优化器的判断出现偏差，就会选择低效的执行方式。
查询计划不优的常见原因
要解决问题首先需要找到根源，PostgreSQL查询计划不优通常和以下几个方面有关：
- 统计信息过时：优化器依赖pg_statistic系统表存储的表数据分布统计信息生成计划，如果表数据频繁增删改后没有更新统计信息，优化器对行数、数据分布度的判断就会出错，进而选择错误的计划。
- 代价参数配置不合理：PostgreSQL的优化器基于代价模型工作，seq_page_cost、random_page_cost、cpu_tuple_cost等参数决定了不同操作的成本权重，默认配置可能和实际硬件环境不匹配，导致优化器偏好错误的操作。
- 索引设计不当：索引缺失、索引类型不匹配查询条件、索引列顺序不符合查询前缀规则，都会让优化器无法选择高效的索引扫描，转而使用全表扫描。
- 复杂查询写法问题：比如不必要的子查询嵌套、没有合理限制结果集、在条件中对索引列使用函数或类型转换，都会导致优化器无法识别可用索引。
调整执行计划的详细步骤
第一步：更新统计信息
当表数据发生较大变化后，首先要手动更新统计信息，让优化器获取准确的数据分布：
-- 更新单个表的统计信息，默认采样比例为0.1，可根据表大小调整 ANALYZE VERBOSE your_table_name; -- 如果表数据量很大，可以调整采样比例，比如采样30%的数据 ALTER TABLE your_table_name SET (autovacuum_analyze_scale_factor = 0.3); -- 之后触发自动分析或者手动执行ANALYZE
更新后可以通过pg_stats视图查看统计信息是否正确，比如查看某列的不同值数量、空值比例等：
SELECT attname, n_distinct, null_frac FROM pg_stats WHERE tablename = 'your_table_name' AND attname = 'your_column_name';
第二步：调整代价模型参数
根据实际的硬件环境调整代价参数，让优化器的成本计算更符合实际执行情况：
| 参数名 | 默认值 | 调整建议 |
|---|---|---|
| seq_page_cost | 1.0 | 顺序扫描页面的成本，机械硬盘保持默认，SSD可以降低到0.1-0.5 |
| random_page_cost | 4.0 | 随机扫描页面的成本，机械硬盘保持默认，SSD可以降低到1.0-2.0 |
| cpu_tuple_cost | 0.01 | 处理单条元组的CPU成本，一般不需要调整 |
| cpu_index_tuple_cost | 0.005 | 处理索引条目的CPU成本，一般不需要调整 |
修改参数可以通过修改postgresql.conf配置文件，或者会话级别临时调整：
-- 会话级别临时调整，仅当前会话生效 SET random_page_cost = 1.5; -- 查看当前参数值 SHOW random_page_cost;
第三步：优化索引设计
根据查询语句的特点设计合适的索引，避免无效索引：
- 如果查询条件包含多列，创建符合最左前缀原则的复合索引，比如查询条件是
WHERE a = 1 AND b = 2，可以创建(a,b)的复合索引。 - 如果查询中有范围查询，范围列放在复合索引的最后，比如
WHERE a = 1 AND b > 10，索引应该是(a,b)。 - 对于文本类型的模糊查询，可以考虑使用pg_trgm扩展创建模糊查询索引：
-- 创建pg_trgm扩展 CREATE EXTENSION IF NOT EXISTS pg_trgm; -- 创建模糊查询索引，支持LIKE '%keyword%'的查询 CREATE INDEX idx_your_table_name_col_trgm ON your_table_name USING gin (your_column_name gin_trgm_ops);
第四步：固化最优执行计划
如果某些查询的计划调整困难，或者优化器偶尔会选择低效计划，可以使用pg_hint_plan扩展来固化执行计划：
-- 先安装pg_hint_plan扩展，不同版本安装方式略有差异，一般通过包管理器安装后创建扩展 CREATE EXTENSION IF NOT EXISTS pg_hint_plan; -- 使用hint指定使用索引扫描，比如让查询使用idx_your_table_name_col索引 /*+ IndexScan(your_table_name idx_your_table_name_col) */ SELECT * FROM your_table_name WHERE your_column_name = 'test';
第五步：验证调整效果
每次调整后，都要通过EXPLAIN ANALYZE命令查看实际执行计划，对比调整前后的执行时间和成本：
-- 查看查询的实际执行计划，ANALYZE会真正执行查询，输出实际执行时间和行数 EXPLAIN ANALYZE SELECT * FROM your_table_name WHERE your_column_name = 'test';
重点关注执行计划中的操作类型（比如Seq Scan、Index Scan、Hash Join等）、估算行数和实际行数的偏差、总执行时间，逐步调整直到选择最优计划。
注意事项
调整执行计划时不要一次性修改多个参数，建议每次只调整一个变量，这样可以明确每个调整带来的效果。另外生产环境调整前一定要在测试环境验证，避免参数修改影响其他查询的性能。如果查询计划问题反复出现，还要排查是否有锁等待、表膨胀等问题，这些问题也可能间接导致优化器生成错误计划。
PostgreSQL查询计划优化执行计划调整代价模型统计信息修改时间：2026-05-30 21:25:45