PostgreSQL中records表查询缓慢求助：带索引仍耗时15秒

别急，咱们一步步来排查这个问题——虽然你已经给created_at字段建了索引，但还是有不少细节会导致这条简单的COUNT查询变慢，150万条数据其实不算特别大，大概率不是单纯表大的锅。

• 先确认索引是否真的被查询使用
  第一步得搞清楚数据库到底走没走你建的索引。执行这条命令查看执行计划：

  EXPLAIN ANALYZE SELECT COUNT(*) FROM project.records WHERE created_at > NOW() - INTERVAL '1 day';
  

  如果结果里显示Seq Scan（全表扫描）而不是Index Scan，那说明优化器没选索引，得接着找原因。

• 更新表的统计信息
  PostgreSQL的查询优化器依赖准确的统计信息来选最优计划，如果统计信息过时，它可能会错误地认为全表扫描比走索引更快。执行这条命令更新统计信息：

  ANALYZE project.records;
  

  之后再重新跑一遍上面的EXPLAIN ANALYZE，看看是不是用上索引了。

• 检查索引类型与有效性
  确保你建的是适合timestamp字段的B-tree索引（这是默认类型，一般没问题），索引语句应该类似这样：

  CREATE INDEX idx_records_created_at ON project.records(created_at);
  

  如果索引是表达式索引或者建错了字段，那肯定起不到作用。另外也可以检查索引是否失效：

  SELECT * FROM pg_index WHERE indrelid = 'project.records'::regclass;
  

  要是索引状态不对，直接重建它就行：

  REINDEX INDEX idx_records_created_at;
  

• 排查数据库负载与锁情况
  有时候查询慢不是索引的问题，而是数据库当时在跑其他耗资源的操作（比如大备份、批量写入、其他复杂查询），导致CPU、IO被占满。你可以用pg_stat_activity看看当前数据库活动：

  SELECT pid, query, state, wait_event_type, wait_event FROM pg_stat_activity WHERE query LIKE '%records%COUNT%';
  

  要是看到有锁等待或者高负载，得先处理那些占资源的操作。

• 清理索引碎片
  如果你的表经常有插入、删除、更新操作，索引会产生碎片，导致扫描效率下降。可以执行VACUUM ANALYZE清理垃圾数据并更新统计：

  VACUUM ANALYZE project.records;
  

  要是碎片特别多，直接重建索引的效果会更好，就是上面提到的REINDEX命令。

• 长期方案：分区表（可选）
  如果数据还在持续增长，未来可能超过千万级，可以考虑按created_at字段做分区（比如按天或按月分区）。这样查询一天的数据时，数据库只需要扫描对应分区的数据，不用遍历全表，能大幅提升查询速度。

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