SQL 如何实现“游标分页”（keyset pagination）避免深分页慢_网络技术

发布时间 - 2026-01-29 00:00:00 点击率：次

keyset pagination 是一种基于排序字段值的游标分页方法，比 OFFSET 更快，因其跳过扫描直接定位；要求排序字段具唯一性，SQL 通过比较上一页末记录的 (created_at, id) 值实现高效分页。

OFFSET 分页在数据量大、页码靠后时会越来越慢，因为数据库必须扫描并跳过前面所有行。keyset pagination（又称游标分页）不依赖行号，而是用上一页最后一条记录的排序字段值作为下一页的起点，跳过扫描过程，直接定位。

它本质是“基于值的分页”，要求排序字段有唯一性或组合唯一性（比如 created_at, id），否则可能漏行或重复。

常见错误现象：OFFSET 100000 LIMIT 20 执行秒级甚至超时；而等价的 keyset 查询毫秒级返回。

核心是把“第 N 页”转换成“大于上一页最后一条的排序键”。假设按 created_at DESC

, id DESC 排序，且每页取 20 条：

第一页：直接查最大值，SELECT * FROM posts ORDER BY created_at DESC, id DESC LIMIT 20
后续页：用上一页最后一条的 (created_at, id) 做条件，注意方向要和 ORDER BY 一致
第二页示例（假设上一页最后一条是 ('2025-05-01 10:00:00', 12345)）：
SELECT * FROM posts WHERE (created_at, id)

关键点：

MySQL 5.7 不支持行值比较，得改写为复合条件：

等价于上面的 MySQL 5.7 写法：
WHERE created_at

PostgreSQL 支持标准行值语法，但要注意：

常见坑：

游标不是随意拼的字符串，它是排序键的编码结果。推荐做法：

服务端从查询结果中取最后一条的排序字段，JSON 序列化后 Base64 编码，例如：base64_encode(json_encode(['2025-05-01 10:00:00', 12345]))
前端只传这个字符串，后端解码后直接用于 WHERE，避免类型解析错误
务必校验解码后的数组长度和字段类型，防止注入或越界（如传入 ["abc", null]）
不要用主键 ID 单独做游标——如果业务允许 ID 不连续或有删改，极易漏数据

游标分页真正难的不是写 SQL，而是保证排序键稳定、索引有效、编码防篡改。一旦某条记录的 created_at 被更新，它就可能在下一页重复出现——这点容易被忽略。