ORDER BY必须包含唯一决胜列，否则ROW_NUMBER()分页结果会漂移；正确做法是ORDER BY字段后追加非空唯一列（如id）兜底，并避免误用PARTITION BY或在大结果集上滥用窗口函数。
ORDER BY 必须包含唯一决胜列，否则窗口分页结果会漂移
窗口函数分页（如用 ROW_NUMBER() 生成序号再过滤）看似绕开了 OFFSET，但若 OVER() 中的 ORDER BY 不够确定，结果依然不可靠。数据库不会自动补全排序依据——相同排序值的行，物理顺序可能因索引变更、并发写入或执行计划调整而改变。
常见错误现象：
- 两次执行同一
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY status) rn FROM tasks) t WHERE rn BETWEEN 11 AND 20，返回不同记录 - 分页跳转后某条数据在第 1 页和第 2 页重复出现，或直接消失
正确做法是强制添加至少一个**非空、唯一、有索引**的列作为第二排序项：
-
ORDER BY status, id ASC——id是主键，确保每组status内严格有序 -
ORDER BY created_at DESC, id DESC—— 时间字段可能重复，id做决胜列 - 若排序字段允许
NULL，显式加NULLS LAST（PostgreSQL/MySQL 8.0+）或等效处理（如CASE WHEN score IS NULL THEN 1 ELSE 0 END, score DESC）
PARTITION BY 与分页目标不匹配时，行号逻辑会错乱
用 ROW_NUMBER() 分页，本质是给「整个结果集」打全局序号；但如果误加 PARTITION BY，就变成按组编号，rn = 11 可能落在第 5 个分组里，完全偏离分页预期。
典型误用场景：
- 想分页展示全部订单，却写了
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)→ 每个用户都从 1 开始编号，WHERE rn BETWEEN 11 AND 20实际查的是“每个用户第 11–20 新的订单”，不是全局第 11–20 条 - 业务要“每页 20 个用户”，但 JOIN 订单表后未先聚合或去重，直接窗口编号 → 一个用户多条订单导致行号膨胀，第 1 页只覆盖 3 个用户
解决路径很明确：
- 纯分页需求：去掉
PARTITION BY，只留ORDER BY - 需先按主表分页（如用户），再查关联数据：用子查询先取
SELECT id FROM users ORDER BY id LIMIT 20 OFFSET 40，再JOIN或IN补详情 - 若必须在 JOIN 后分页，确认
ORDER BY字段组合能唯一标识每一行（如u.id, o.id）
窗口函数物化开销大，大结果集下反而比 OFFSET 更慢
ROW_NUMBER() OVER (ORDER BY ...) 要求数据库先对**整个中间结果集**排序并编号，再过滤。当 JOIN 后结果达百万行，这个物化过程比 LIMIT 10000, 20 还吃资源——后者至少能用索引下推跳过部分扫描，而窗口函数常触发临时表和磁盘排序。
性能临界点取决于三件事：
- JOIN 后预估行数是否可控（
-
ORDER BY字段是否有覆盖索引（如(status, id)对应ORDER BY status, id） - 数据库版本是否支持优化（MySQL 8.0.22+ 对小窗口有缓存，PostgreSQL 14+ 支持增量物化）
实操建议：
- 先 EXPLAIN，看执行计划里有没有
WindowAgg或Sort节点出现在最外层，且 Rows 显著大于你要的页大小 - 若 JOIN 后太大，改用键集分页：
WHERE created_at - 别迷信“窗口函数一定更好”——它只是换了一种不稳定来源，没解决根本的排序确定性问题
CTE 或子查询层级里漏掉排序字段，会导致外层过滤失效
窗口函数结果不能直接在 WHERE 中引用，这是 SQL 执行顺序决定的。但更隐蔽的问题是：有人把排序逻辑写在 CTE 外层，导致窗口计算时实际没排序。
错误写法示例：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER () AS rn -- 这里没写 ORDER BY！ FROM orders ) SELECT * FROM ranked WHERE rn BETWEEN 11 AND 20;
这在 PostgreSQL 直接报错，在 MySQL 可能跑通但结果随机。真正起作用的永远是 OVER() 里的 ORDER BY，不是外层 SELECT 的 ORDER BY。
务必检查：
- 所有
ROW_NUMBER()、RANK()调用，OVER()内是否含完整ORDER BY（含决胜列） - CTE 中的排序不传递到外层，外层
ORDER BY只影响最终输出顺序，不影响窗口编号 - 如果用了
PARTITION BY，确认它符合业务分组意图（比如PARTITION BY dept_id, region而非仅dept_id）
稳定分页最难的从来不是语法，而是让每一行在任意时刻都能被同一个确定性规则锚定——这要求你亲手写出那个规则，而不是依赖数据库的“默认”。
