优化count(*)查询及分页：无需count(*)仍显示页码（Erlang epgsql）

如果不想依赖耗时的count(*)但又要展示页码，优先考虑近似计数+键集分页的组合，或者以下几种落地性强的方案：

• 近似计数+静态页码展示：
  后台通过定时任务（比如每小时执行一次）跑count(*)，把结果存在Redis或数据库缓存表中，前端用这个近似值计算总页码。大部分业务场景（电商列表、内容平台等）都能接受细微的行数误差，同时配合键集分页保证数据查询效率——每次查询带上上一页最后一条数据的主键（或唯一排序键），用WHERE id > last_id LIMIT page_size的方式获取下一页，规避偏移量分页的性能瓶颈。

• 键集分页+动态页码提示：
  无需全局精确总页码，只显示当前页、上一页、下一页，同时标注“共约X页”（X来自近似计数）。另外，每次查询时多取1条数据（比如LIMIT page_size + 1），通过判断返回结果数量是否大于page_size，就能确定是否还有下一页，不用总count也能明确分页边界。如果用户需要跳转到指定页码，可以用主键范围估算（比如每页10条，第50页的主键起始值约为490，直接用WHERE id >= 490 LIMIT 10定位，误差在可接受范围内）。

• 分段维度分页：
  按数据的天然维度（创建日期、分类ID等）拆分，先让用户选择大分段（比如“2024年5月”），再在分段内分页。分段内的count可以提前缓存，因为分段数量少，统计速度快，用户查询范围也更聚焦，体验更流畅。

针对PostgreSQL（epgsql默认对接的数据库）的count(*)慢问题，按优先级推荐以下优化手段：

• 利用覆盖索引加速：
  PostgreSQL的count(*)会优先选择体积最小的索引扫描，所以建一个轻量的单列索引（比如主键索引，或仅包含过滤条件的索引），让count查询走索引而非全表扫描。比如如果查询有固定过滤条件WHERE status = 1，就建CREATE INDEX idx_status ON your_table(status);，之后SELECT COUNT(*) FROM your_table WHERE status = 1;会直接扫描这个小索引，速度比扫全表快数倍。

• 使用内置近似行数统计：
  直接读取PostgreSQL自动维护的统计信息，耗时毫秒级：

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

  这个值是近似行数，误差一般在5%以内，数据更新频繁的话可以定期执行VACUUM ANALYZE your_table;更新统计信息，适合不需要精确值的场景。

• 缓存count结果：
  把精确count值存在Redis等缓存中，写操作（新增/删除数据）后异步更新缓存，或用定时任务周期性刷新。如果业务允许少量延迟，这是最快的方式——查询时直接读缓存，完全避免count开销。

• 分段统计并行求和：
  把大表按主键或时间范围拆分成多个段，分别count每个段再求和，epgsql可开多个连接并行执行这些分段查询，总耗时远低于单条count查询。示例：

  SELECT SUM(cnt) FROM (
    SELECT COUNT(*) AS cnt FROM your_table WHERE id BETWEEN 1 AND 100000
    UNION ALL
    SELECT COUNT(*) AS cnt FROM your_table WHERE id BETWEEN 100001 AND 200000
    -- 更多分段...
  ) AS t;
  

• 避免不必要的额外开销：
  count查询里不要加冗余WHERE条件，确保条件字段有索引；不要用count(column)代替count(*)——count(column)会过滤null值，且可能无法走最优索引，count(*)是PostgreSQL统计行数的最优方式。

内容的提问来源于stack exchange，提问作者Sam K Varghese