为何PostgreSQL从3亿条数据查200条时未用timestamp索引而用SeqScan？

这问题我之前帮团队排查过好几次，PostgreSQL放弃索引走全表扫描，核心原因是优化器估算的成本认为全表扫比索引扫描更划算——哪怕你只取200条记录。下面是几个最常见的原因和对应的排查方向：

1. 统计信息过时或不准确 #

PostgreSQL的查询优化器完全依赖pg_statistics里的统计数据来判断执行计划。如果你的events表数据量很大（3亿条），但很久没更新统计信息，优化器可能完全不知道sending字段的数据分布：

• 它可能误以为你查询的条件会命中大量记录，觉得索引回表的成本远高于全表扫；
• 或者它不知道sending字段的取值范围，没法准确估算索引扫描的效率。

解决方法：
先手动更新统计信息：

VACUUM ANALYZE events;

如果表更新频繁，建议检查autovacuum相关配置，确保自动统计信息更新正常运行。

2. 查询条件破坏了索引可用性 #

如果你的查询用了函数包装sending字段，比如：

SELECT * FROM events WHERE DATE(sending) = '2024-05-01' LIMIT 200;

这种情况下，PostgreSQL无法直接使用sending上的索引——因为索引是基于原始timetamp值建立的，而函数处理后的值和索引不匹配。

解决方法：
把查询条件改成基于原始字段的范围查询，让索引能直接匹配：

SELECT * FROM events 
WHERE sending >= '2024-05-01 00:00:00' 
  AND sending < '2024-05-02 00:00:00' 
LIMIT 200;

3. 索引需要回表，成本被高估 #

如果你的sending索引只包含sending字段，而查询需要返回其他多个字段，那么索引扫描后需要回表（通过索引里的行号去主表读取完整数据）。对于3亿条数据的大表，PostgreSQL的优化器可能会认为：

• 回表的随机IO成本太高，哪怕只回表200次；
• 尤其是如果表的行很宽，或者缓存命中率低，优化器会倾向于全表扫。

解决方法：
创建覆盖索引，把查询需要的所有字段都包含进去，这样不需要回表就能满足查询：

CREATE INDEX idx_events_sending_covering 
ON events(sending) 
INCLUDE (col1, col2, col3); -- 替换成你查询需要的字段

4. 成本参数配置不符合实际硬件 #

PostgreSQL默认的成本参数是针对机械硬盘设置的，比如random_page_cost（随机IO成本）默认值是4，而seq_page_cost（顺序IO成本）是1。如果你的数据库用的是SSD，随机IO的实际成本远低于机械硬盘，优化器还按照默认值估算的话，会觉得回表的成本极高，从而放弃索引。

解决方法：
调整random_page_cost的值（比如调到1.1-1.5），让优化器更愿意选择索引扫描：

ALTER SYSTEM SET random_page_cost = 1.1;
SELECT pg_reload_conf();

注意：这个调整是全局的，最好先在测试环境验证后再应用到生产。

5. 数据分布极端，优化器误判 #

如果sending字段的数据分布极不均匀——比如90%的记录都集中在最近一周，而你的查询刚好命中这个时间段，优化器可能估算符合条件的记录占比很高（比如超过10%），觉得全表扫比索引扫描更快。哪怕你加了LIMIT 200，如果优化器没意识到可以通过索引快速定位前200条，还是会选全表扫。

解决方法：
如果是要取最新/最早的200条，确保查询里有ORDER BY sending DESC/ASC LIMIT 200，这样优化器会知道可以通过索引直接获取排序后的结果，不需要扫全表。

如果能把EXPLAIN ANALYZE的具体结果贴出来（比如估算行数和实际行数的差异、执行计划的细节），就能更精准地定位问题了。

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