答案：排查PostgreSQL索引失效需分析执行计划、统计信息、SQL写法及成本模型。使用EXPLAIN ANALYZE检查是否走顺序扫描、预估行数是否准确；运行ANALYZE更新统计信息，必要时提高采样级别；避免在索引列使用函数、负向查询、前置通配符LIKE或隐式类型转换；调整random_page_cost等参数优化成本模型；定期维护并监控索引使用情况，结合pg_stat_user_indexes和pg_stat_statements定位问题。
PostgreSQL中索引失效问题常导致查询性能急剧下降。要排查这类问题，不能只看执行计划是否用了索引，而需深入理解优化器的决策逻辑。核心思路是：确认优化器为何放弃索引扫描，并针对性调整。
检查执行计划与索引使用情况
使用 EXPLAIN (ANALYZE, BUFFERS) 查看实际执行路径，重点关注以下几点：
-
是否走了顺序扫描（Seq
Scan）而非索引扫描（Index Scan / Index Only Scan）？如果是，说明优化器认为全表扫描更快。 - 查看 rows 数量预估是否准确，若实际行数与预估差异大，可能是统计信息不准导致决策错误。
- 关注 cost 值，特别是启动成本和总成本，判断优化器权衡依据。
Scan）而非索引扫描（Index Scan / Index Only Scan）？如果是，说明优化器认为全表扫描更快。分析统计信息准确性
PostgreSQL依赖统计信息估算选择率。若统计不准确，优化器会误判索引效率。
- 运行 ANALYZE 表名 更新统计信息，尤其是频繁变更的表。
- 检查 pg_stats 视图中的 n_distinct、most_common_vals 等字段，确认关键列的分布是否反映真实情况。
- 对低基数列或存在明显倾斜的数据，考虑增加统计采样级别：ALTER TABLE 表名 ALTER COLUMN 列名 SET STATISTICS 1000;
识别导致索引失效的常见写法
某些SQL结构天然阻碍索引使用：
- 在索引列上使用函数或表达式，如 WHERE UPPER(name) = 'ABC'，除非建了函数索引。
- 使用负向查询，如 WHERE status != 'done' 或 NOT IN，这类条件通常无法有效利用B-tree索引。
- 模糊匹配以通配符开头：LIKE '%abc' 不走索引；LIKE 'abc%' 可以。
- 隐式类型转换，如字符串字段传入数字值，可能导致索引失效。
理解优化器的成本模型与配置参数
优化器基于成本选择执行计划，受多个GUC参数影响：
- random_page_cost：默认4.0，若使用SSD建议调低至1.1~2.0，提升索引扫描吸引力。
- cpu_tuple_cost 和 seq_page_cost：调整这些值可改变优化器对I/O与CPU的权衡。
- enable_indexscan、enable_seqscan：可用于临时强制开关某种扫描方式做对比测试（生产慎用）。
通过 SET 临时修改参数并重新执行 EXPLAIN，观察执行计划变化，有助于验证假设。
监控与预防建议
定期维护是避免索引失效的基础：
- 确保自动 vacuum 和 analyze 正常运行。
- 对大表考虑分区 + 局部索引策略，减少单个索引规模。
- 使用 pg_stat_user_indexes 监控索引使用频率，清理长期未使用的索引。
- 结合 pg_stat_statements 定位高频慢查询，优先优化。
