PostgreSQL如何实现高性能分页_结合ROW_NUMBER或游标-SQL-PHP中文网

LIMIT OFFSET在大数据量下变慢是因为数据库需逐行扫描并跳过OFFSET行，时间复杂度O(OFFSET+LIMIT)，即使有索引也无法跳过扫描；游标分页通过索引范围查询避免跳行，性能更优。

postgresql如何实现高性能分页_结合row_number或游标

为什么 LIMIT OFFSET 在大数据量下会变慢

因为 PostgreSQL 必须从排序结果的开头逐行扫描，跳过 OFFSET 指定的全部行，才能取到目标数据。当 OFFSET 是 100 万时，数据库实际读了 100 万 + LIMIT 行，时间复杂度是 O(OFFSET + LIMIT)。即使有索引，只要没用上“跳过前 N 行”这个能力，它就还是得走一遍。

ROW_NUMBER() 真的比 OFFSET 快吗

不一定快，甚至可能更慢——尤其在没加合适索引、或返回字段多、或排序列不唯一时。ROW_NUMBER() 需要先对全表（或满足 WHERE 条件的部分）完成完整排序并编号，再过滤，本质仍是“全量计算 + 截断”。

只适合中小数据集（比如
必须确保 ORDER BY 列有索引，否则性能雪崩；推荐组合索引，例如 CREATE INDEX idx_orders_created_at_id ON orders(created_at DESC, id DESC)
避免在 OVER() 里用函数或表达式排序，比如 ORDER BY lower(name)，这会让索引失效
如果排序列存在重复值，ROW_NUMBER() 生成的序号是不确定的（除非补上唯一列保序），可能导致同一页数据重复或遗漏

游标分页（Keyset Pagination）怎么写才有效

这是真正能解决深分页性能问题的方法：它不依赖“第几页”，而是记住上一页最后一条记录的排序键值，用 WHERE 直接定位下一页起点。查询复杂度稳定在 O(log N)，和页码无关。

基础写法（按 created_at DESC 分页）：

SELECT id, name, created_at
FROM orders 
WHERE created_at

必须保证排序字段有索引，且方向一致（如 created_at DESC 对应 WHERE created_at ）
如果排序字段可能重复（比如多个订单同一秒创建），一定要追加一个唯一列（如 id）作为第二排序条件，并在 WHERE 中一并约束：
```
WHERE (created_at, id) 
```
前端不能传 page=1000，只能传上一页最后一条的 cursor（通常是 base64 编码的排序键值组合）
无法直接跳转中间页；但对 API 场景（如无限滚动、Feed 流）完全够用，且更稳定——不会因新数据插入导致页偏移