这种明明建好索引却突然失效的情况确实闹心，我来帮你一步步排查问题，先搞懂为什么PostgreSQL放着索引不用，再给你临时强制方案和长期修复的办法。

一、先搞清楚：为什么PostgreSQL不选你的索引？ #

PostgreSQL的查询优化器会基于成本估算选执行计划，它放弃索引选全表扫描（Seq Scan）通常有这几个常见原因，结合你的情况逐一排查：

1. 统计信息过时或不准确
   你已经跑了analyze firma2.klient，但对于定长字符（bpchar）这类字段，默认的统计采样率可能不够精准，导致优化器误判“全表扫比索引扫更便宜”。

2. 索引本身可能损坏或失效
   虽然你重启了服务器，但索引文件可能在之前的操作中出现损坏，导致优化器认为它不可用。

3. 数据类型/匹配逻辑的隐形坑
   你的nimi字段是character(100)（也就是bpchar，定长字符），这种类型会自动给存储的字符串补空格到指定长度。比如你存John，实际存储的是John后面跟96个空格。如果你的查询条件是nimi='John'，其实是在找**完全等于John（不带空格）**的行，这和实际存储的数据不匹配——哪怕索引有效，也查不到数据，优化器可能因此觉得“索引没用”，直接全表扫。

4. 成本参数的隐性变化
   虽然你说配置是默认值，但可以再确认：cpu_index_tuple_cost（0.005）比cpu_tuple_cost（0.01）低，理论上优化器应该优先选索引。但如果近期有过配置变更（哪怕是临时的），可能影响了估算。

二、临时应急：强制PostgreSQL使用指定索引 #

如果现在需要立刻让查询变快，可以用这两种方法：

方法1：用查询提示（Query Hint）指定索引 #

PostgreSQL 12+支持USE INDEX语法，直接告诉优化器用哪个索引：

SELECT * FROM firma2.klient USE INDEX (klient_nimi_idx) WHERE nimi='John';

如果这个还不生效，可以用更严格的FORCE INDEX（和MySQL语法兼容，PostgreSQL也支持）：

SELECT * FROM firma2.klient FORCE INDEX (klient_nimi_idx) WHERE nimi='John';

方法2：临时关闭全表扫描的开关 #

通过会话级别的参数设置，让优化器无法选择全表扫描，只能用索引。注意这个设置只在当前事务/会话生效，不会影响全局：

-- 临时关闭全表扫描
SET LOCAL enable_seqscan = off;
-- 执行你的查询
SELECT * FROM firma2.klient WHERE nimi='John';
-- 恢复默认设置
RESET LOCAL enable_seqscan;

三、长期修复：从根源解决索引失效问题 #

临时强制只是权宜之计，找到问题根源才能避免再次出现：

1. 重建索引+重新收集精准统计信息 #

先重建索引，确保索引本身没有损坏：

-- 重建指定索引
REINDEX INDEX firma2.klient_nimi_idx;
-- 或者重建整个表的所有索引（更彻底）
REINDEX TABLE firma2.klient;

然后用更详细的命令收集统计信息，提高采样率让优化器更精准：

-- 给nimi字段提高统计采样率（默认是100，设为1000更精准）
ALTER TABLE firma2.klient ALTER COLUMN nimi SET STATISTICS 1000;
-- 带详细输出的Vacuum Analyze，同时清理死元组+更新统计
VACUUM ANALYZE VERBOSE firma2.klient;

2. 修复bpchar类型的隐形匹配问题 #

定长字符bpchar的空格补全逻辑是很多坑的源头，建议你：

• 先验证查询匹配问题：试试查询带空格的版本，看能不能找到数据：

  -- 生成和字段长度匹配的查询条件（John + 96个空格）
  SELECT * FROM firma2.klient WHERE nimi = 'John' || repeat(' ', 96);
  -- 或者用trim忽略空格查询
  SELECT * FROM firma2.klient WHERE trim(nimi) = 'John';
  

• 如果确实是空格导致的不匹配，长期建议把character(100)改成varchar(100)（变长字符，不会自动补空格），这能从根源避免这类匹配问题：

  -- 先备份表，再修改字段类型
  ALTER TABLE firma2.klient ALTER COLUMN nimi TYPE varchar(100);
  -- 修改后记得重建索引
  REINDEX INDEX firma2.klient_nimi_idx;
  

3. 排查“突然失效”的触发点 #

你提到之前能用今天突然不行，回忆一下最近有没有做过这些操作：

• 有没有修改过表结构（比如改nimi的类型、排序规则）？
• 有没有批量插入/删除过大量数据？导致表的统计信息剧烈变化，优化器重新计算成本后选择全表扫描。
• 有没有调整过PostgreSQL的配置参数（比如enable_seqscan、成本参数）？

4. 验证索引的可用性 #

最后确认索引本身是有效的，查询系统表看看索引状态：

-- 查看指定表的索引信息
SELECT indexname, indexdef, indisvalid 
FROM pg_indexes 
WHERE schemaname='firma2' AND tablename='klient';

如果indisvalid是t，说明索引是有效的；如果是f，说明索引需要重建。

四、总结 #

先试试临时强制索引的方法解决当前的慢查询问题，然后按长期修复的步骤逐一排查，重点关注bpchar类型的空格匹配问题和统计信息的准确性——这两个是PostgreSQL索引突然失效的常见根源。如果重建索引+更新统计信息后还是不行，大概率是数据类型匹配的问题，改成varchar应该能彻底解决。