API中高流量场景下列表分页的实现方案咨询

核心结论 #

直接给准话：完全不需要Solr这类搜索引擎，PostgreSQL就能搞定分页需求，只要做好优化和缓存配合，数据库根本不会被压垮。

一、PostgreSQL分页的正确打开方式 #

用LIMIT/OFFSET做分页是基础操作，但偏移量一大（比如翻到第1000页），性能会崩——因为数据库得先扫完前面999页的内容。换用键集分页就解决了这个问题：

• 以上一页最后一条数据的唯一有序标识（比如ID、带唯一约束的创建时间戳）作为查询条件，举个例子：

  SELECT id, title, create_time FROM articles 
  WHERE id < :last_page_max_id 
  ORDER BY id DESC 
  LIMIT 20;
  

  这种方式直接通过定位最后一条数据的位置来取页，不会扫描多余行，性能随页数增加也不会下降。
• 给排序字段加复合索引：比如按ID倒序查，就建(id DESC)索引；如果是按时间排序，得加个ID兜底（防止多条数据时间相同），建(create_time DESC, id DESC)索引，让查询直接走索引，不用回表捞数据。
• 单页数据量别贪多：20-30条足够，减少单次查询的IO和传输压力。

二、数据库防压的关键措施 #

优化后的PostgreSQL扛高流量分页完全没问题，再补几个保险措施：

• 读写分离：把分页查询都扔到只读副本上，主库只处理写操作，分摊压力。
• 用连接池控连接：比如PgBouncer，别让大量请求直接打满数据库的连接数，导致拒绝服务。
• 盯紧慢查询：定期看慢SQL日志，发现分页查询变慢就调索引或者换分页方式。

三、Redis缓存的正确用法 #

既然存不下完整列表，就按页拆分缓存：

• 用首页列表_页码当Redis键，缓存对应页的序列化数据（比如JSON），过期时间设5-15分钟，平衡实时性和缓存命中率。
• 热点页特殊处理：第1页访问量肯定最高，给它设更长的过期时间，或者数据更新时主动刷新，不用等过期。
• 数据更新主动清缓存：只要列表里的内容有增删改，直接删掉对应页的缓存键，或者更新缓存，避免用户看到旧数据。
• 防缓存穿透：如果某个页码不存在（比如超出总页数），缓存个空值，别让请求一直怼数据库。

四、为什么没必要用Solr？ #

Solr这类工具主打全文检索、复杂多维度过滤排序，但你只需要分页，完全没用到它的核心能力。引入Solr反而会增加系统复杂度——要部署维护、要同步数据，纯纯的画蛇添足。PostgreSQL优化好足够用。

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