PostgreSQL索引未生效：查询仍触发全表扫描而非索引扫描求助

核心原因分析 #

从你的执行计划来看，符合查询条件的行（6305万+）占总行数（约6560万）的96%以上。PostgreSQL优化器默认认为，当需要读取的数据接近表的大部分时，全表扫描（顺序读）的效率远高于索引扫描（哪怕是覆盖索引）——因为顺序读的IO开销远低于索引的随机读（或索引遍历的额外开销），优化器会优先选择成本更低的执行路径。

排查与解决步骤 #

1. 验证索引扫描是否真的更高效 #

强制关闭全表扫描，测试索引扫描的实际性能：

SET enable_seqscan = off;
EXPLAIN (analyze, buffers) 
SELECT date, cumpany, host 
FROM mytable 
WHERE date < (now() - INTERVAL '10 days');

如果执行时间比全表扫描更长，说明优化器的选择是合理的；如果更短，继续下一步排查。

2. 更新表统计信息 #

如果统计信息过时，优化器可能对符合条件的行数估计错误，导致选择错误的执行计划：

ANALYZE mytable;

更新后重新执行原查询，看是否切换为索引扫描。

3. 检查索引有效性 #

确认当前创建的覆盖索引是有效的：

SELECT idxname, indisvalid 
FROM pg_index 
WHERE indrelid = 'mytable'::regclass;

如果indisvalid为false，需要重建索引：

REINDEX INDEX ix_mytable_company;

4. 考虑表分区优化 #

如果表数据量极大（数千万级），按date字段分区（比如按月/按周分区）是更长期的优化方案：

• 分区后，查询只会扫描符合条件的旧分区，避免全表扫描
• 可以直接归档或删除过期分区，降低存储和查询开销

5. 调整优化器参数（谨慎操作） #

如果确认索引扫描更高效，但优化器仍不选择，可以临时调整优化器的成本参数（不建议长期修改全局参数）：

-- 降低索引扫描的相对成本
SET random_page_cost = 1.1;
-- 或提高全表扫描的成本
SET seq_page_cost = 2.0;

调整后重新测试查询性能。

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