如何进一步优化50万条cars表的数据库查询性能？

针对你遇到的SELECT COUNT(*) FROM cars耗时过长的问题，以及后续的分页性能优化，给你几个实际可行的方向：

• 去掉不必要的总条数统计
  如果业务上不需要显示"总共有X条数据"这类信息，直接删掉视图里的<%= page_entries_info @cars %>，这会直接砍掉那3.7秒的COUNT查询，是见效最快的优化。

• 用近似计数替代精确COUNT
  PostgreSQL可以通过系统表快速获取近似的表行数，速度几乎是瞬时的，适合不需要绝对精确总条数的场景：

  SELECT reltuples::bigint FROM pg_class WHERE relname = 'cars';
  

  在Rails里可以封装成模型方法调用：

  def self.approx_count
    connection.select_value("SELECT reltuples::bigint FROM pg_class WHERE relname = 'cars'").to_i
  end
  

  用这个近似值替代分页组件的精确计数即可。

• 缓存总条数
  如果必须要精确的总条数，可以把COUNT结果缓存起来：

  • 定时缓存：用Redis存储Car.count的结果，比如每分钟通过定时任务更新一次
  • 异步更新：在车辆创建/删除操作后，用Sidekiq之类的异步任务更新缓存的计数，避免同步操作阻塞请求

• 切换为基于游标的分页（无限滚动）
  放弃传统的页码分页，改用基于游标的方式，完全不需要统计总条数，同时还能解决大偏移量分页的性能问题（比如第1000页的OFFSET 99900会非常慢）。示例代码：

  # 第一页查询
  @cars = Car.order(created_at: :desc, id: :desc).limit(100)
  # 下一页查询，用上一页最后一条记录的created_at和id作为游标
  last_car = @cars.last
  @next_cars = Car.where('created_at < ? OR (created_at = ? AND id < ?)', last_car.created_at, last_car.created_at, last_car.id)
                  .order(created_at: :desc, id: :desc)
                  .limit(100)
  

  这种方式适合前端做无限滚动的场景，用户体验也更流畅。

• 优化COUNT(*)的查询效率
  如果一定要保留精确COUNT，可以尝试创建一个轻量化的覆盖索引（不过效果可能有限，因为PostgreSQL会自动选择最小的索引扫描COUNT(*)）：

  CREATE INDEX index_cars_for_count ON public.cars USING btree (id);
  

  注：主键索引已经是基于id的btree，这个优化的提升空间不大，优先考虑前面的方案。

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