PostgreSQL重建索引后查询未走索引扫描却执行顺序扫描求助

嘿，这个问题我碰到过类似的情况，咱们来一步步拆解可能的原因和解决办法：

1. 首先考虑统计信息过期的问题 #

PostgreSQL的查询优化器是基于成本估算的，它依赖表和索引的统计信息来判断用索引还是顺序扫描更划算。当你重建索引后，如果表的统计信息没有及时更新，优化器可能不知道这个索引能高效过滤数据，就会选择顺序扫描。

解决办法很简单，手动更新表的统计信息：

ANALYZE my_table;

执行完之后再跑一遍你的查询，看看是不是回到了Bitmap Index Scan。

2. 确认索引是否真的有效 #

虽然普通CREATE INDEX会立即生效，但万一重建过程中出现了异常（比如中断），索引可能处于无效状态。你可以用下面的SQL检查索引的有效性：

SELECT indisvalid 
FROM pg_index 
WHERE indrelid = 'my_table'::regclass 
  AND indexrelid = 'my_index'::regclass;

如果返回false，说明索引没生效，你需要重新创建一次索引（确保这次没有中断）。

3. 关于创建索引时的锁机制（解答你的疑惑） #

你提到“创建索引时应完成数据索引并锁定写操作”，这里需要区分两种创建索引的方式：

• 普通CREATE INDEX：会对表加SHARE锁，这个锁会阻止所有写操作（INSERT/UPDATE/DELETE），直到索引创建完成。同时，它会一次性扫描全表的现有数据，把所有符合条件的记录都加入索引，所以创建完成后索引是包含所有数据的。
• CREATE INDEX CONCURRENTLY：这种方式不会阻止写操作，但需要两次扫描表，创建时间更长，而且创建过程中索引是无效的，直到第二次扫描完成才会标记为有效。如果你用了这个命令，可能会出现重建后暂时没用到索引的情况。

你的情况应该是用了普通创建方式，所以锁的问题不是导致查询不走索引的原因。

4. 查询的选择性可能影响优化器决策 #

如果你的查询条件返回的行数占表的比例很高（比如超过30%），优化器会认为顺序扫描的成本更低——因为索引扫描需要先查索引再回表取数据，反而不如直接扫全表快。

你可以用EXPLAIN ANALYZE查看详细的查询计划：

EXPLAIN ANALYZE SELECT ...; -- 替换成你的查询语句

对比重建索引前后的计划，看看优化器估算的行数、成本有什么变化，就能明白它为什么选择顺序扫描了。

内容的提问来源于stack exchange，提问作者William Añez