PostgreSQL中如何获取指定游标后的排名评论数据？

要实现基于你自定义score排序的Relay式分页，核心是复用排序逻辑定位游标位置——因为你的排序不是基于主键或简单字段，而是计算得出的score，直接用ID筛选会破坏原排序顺序。

直接数据库层实现方案 #

步骤1：获取游标对应的排序基准值

先拿到游标ID（这里是12）对应的score，以此为筛选后续记录的基准：

SELECT (like_count * 0.5 + reply_count * 3) AS score
FROM comment
WHERE id = 12 AND is_deleted = false;

步骤2：构造分页查询

为了保证排序一致性，需要同时匹配score和ID的组合条件（处理同score的情况，避免漏数据或重复）：

WITH cursor_data AS (
  SELECT 
    id,
    (like_count * 0.5 + reply_count * 3) AS score
  FROM comment
  WHERE id = 12 AND is_deleted = false
)
SELECT 
  c.id,
  (c.like_count * 0.5 + c.reply_count * 3) AS score
FROM 
  comment c, cursor_data cd
WHERE
  c.is_deleted = false
  AND (
    -- 匹配score小于游标记录的条目
    (c.like_count * 0.5 + c.reply_count * 3) < cd.score
    -- 处理score相同但排在游标之后的条目（这里假设同score下按ID升序，和原查询保持一致）
    OR (
      (c.like_count * 0.5 + c.reply_count * 3) = cd.score
      AND c.id > cd.id
    )
  )
ORDER BY c.score desc, c.id asc -- 显式指定排序规则，和原查询对齐
LIMIT 10;

性能优化 #

如果数据量较大，重复计算score会拖慢查询速度，可以创建表达式索引加速：

CREATE INDEX idx_comment_score ON comment (
  (like_count * 0.5 + reply_count * 3) desc,
  id asc
) WHERE is_deleted = false;

这个索引会直接存储计算后的score值，让数据库快速定位符合条件的记录。

与缓存方案的对比 #

你提到的Redis缓存ID列表方法确实可行：

• 优点：实现简单，避免数据库重复计算排序逻辑，适合数据更新频率低的场景
• 缺点：存在数据一致性风险，当评论的点赞/回复数变化时，需要及时更新缓存的排序列表，否则分页结果会不准确

而数据库层面的方案实时性更好，无需维护缓存，但依赖索引优化保证性能。

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