窗口函数不能用于游标分页，因其仅附加编号而不支持状态感知偏移；游标分页需基于有序字段比较（如 (created_at, id) > (?, ?)）实现精准跳转，而 WHERE rn > N 会报错且逻辑错误。

为什么不能直接用窗口函数做游标分页

窗口函数本身不改变结果集行数，ROW_NUMBER()、RANK() 这类函数只是为每行附加一个计算值，无法跳过前 N 行或限制返回条数——而游标分页依赖「从某条记录之后取下一页」，核心是状态感知和有序偏移，不是编号。

常见错误是写成这样：

SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM orders
WHERE rn > 100 AND rn <= 120;

这会报错：Window function is not allowed in WHERE clause。因为窗口函数在逻辑执行顺序中晚于 WHERE，此时 rn 还不存在。

游标分页真正依赖的是 ORDER BY + WHERE 组合

游标分页本质是「基于上一页最后一条记录的排序字段值，查出下一批严格大于它的记录」。它不要求全局编号，只要求排序字段有确定顺序、无重复（或能处理重复）。

关键实操点：

• 必须有一个确定性、高选择性的排序字段，比如 created_at + id 组合（避免时间相同导致游标漂移）
• 查询条件要写成 WHERE (created_at, id) > (, ) 这种行比较语法（PostgreSQL/MySQL 8.0+ 支持），而不是 WHERE created_at >= ? AND id > —— 后者在边界处容易漏数据或重复
• 首次请求没有游标，用 WHERE 1=1 或省略 WHERE，但务必加 LIMIT
• 客户端必须保存上一页最后一条的完整游标值（如 {"created_at": "2024-05-01 10:20:30", "id": 12345}），不能只存单个字段

窗口函数能在游标分页里起什么作用

它不参与分页逻辑，但可用于辅助场景，比如：在返回当前页数据的同时，附带「下一页是否存在」或「是否为最后一页」的提示信息。

例如，查 20 条数据，并多取 1 条用于判断是否还有下一页：

WITH page_plus_one AS (
SELECT *,
 ROW_NUMBER() OVER (ORDER BY created_at, id) AS rn
FROM orders
WHERE (created_at, id) > ('2024-05-01 10:20:30', 12345)
ORDER BY created_at, id
LIMIT 21
)
SELECT *,
 CASE WHEN rn = 21 THEN 'has_next' ELSE 'no_next' END AS pagination_hint
FROM page_plus_one
WHERE rn <= 20;

注意：ROW_NUMBER() 在这里只是给临时结果编号，真正的分页过滤靠的是外层 WHERE rn <= 20，且这个 CTE 必须配合 ORDER BY 和 LIMIT 才可靠。

不同数据库对游标分页的支持差异

PostgreSQL在处理行比较方面表现得最为简洁，它直接支持像这样的写法：WHERE (a, b) > ($1, $2)。MySQL 8.0+ 也有了相关支持，不过在使用时需要留意字符集以及NULL的处理。而SQLite呢，就需要手动展开为 WHERE a > ? OR (a = ? AND b > ) 这样的形式。至于SQL Server，它并没有原生的行比较功能，只能通过 OFFSET-FETCH 来实现类似效果，但要注意，这并不是游标分页，而是基于位置的分页方式，其性能会随着offset的增大而逐渐下降。

还有一点容易被忽视：若排序字段允许 NULL，所有数据库都会将 NULL 排在最前或最后（具体取决于 NULLS FIRST/LAST），但默认行为并不相同。游标分页时必须明确约定，例如统一写成 ORDER BY created_at DESC NULLS LAST, id DESC，同时在 WHERE 条件中同步处理 NULL 游标值。

《夸克》非常好用的免费AI浏览器

下载APP查看