ROW_NUMBER()必须配合OVER子句使用，否则报错；其基本形式为ROW_NUMBER() OVER (ORDER BY column)，分组需加PARTITION BY，且ORDER BY不可省略以确保排序稳定性和编号唯一性。
ROW_NUMBER() 必须配合 OVER 子句使用，否则直接报错
单独写 ROW_NUMBER() 会触发类似 ERROR: window function ROW_NUMBER requires an OVER clause 的错误。它不是普通函数，而是窗口函数，必须明确指定排序逻辑——哪怕你只是想按“查出来顺序”编号，也得写个确定性排序依据。
常见误区是用 ORDER BY RANDOM() 或不加 ORDER BY，但 PostgreSQL/MySQL 8.0+/SQL Server 都不允许省略 ORDER BY；SQLite 虽允许，但结果不可复现。稳妥做法是至少指定一个主键或时间字段：
SELECT ROW_NUMBER() OVER (ORDER BY id) AS rn, name, amount FROM orders;
分区编号要用 PARTITION BY，别和 GROUP BY 混淆
需要“每个用户下订单从 1 开始编号”，就得用 PARTITION BY user_id，而不是在外部套一层 GROUP BY。后者会聚合数据，丢失明细行，而 PARTITION BY 是在保留所有原始行的前提下分组编号。
注意分区字段值相同时，编号才连续重置；如果漏写 ORDER BY，部分数据库（如 SQL Server）会拒绝执行，MySQL 8.0 则可能报错或返回不确定序号：
SELECT user_id, order_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date) AS seq FROM orders;
-
PARTITION BY user_id表示每个user_id独立计数 -
ORDER BY order_date决定每个用户内哪条订单排第 1、第 2… - 若想按下单时间倒序（最新排第 1），改用
ORDER BY order_date DESC
ROW_NUMBER() 和 RANK() / DENSE_RANK() 的区别直接影响去重逻辑
当存在相同排序值（比如两人同分、两单同时间），ROW_NUMBER() 仍强制给唯一序号（1,2,3…），而 RANK() 会跳号（1,2,2,4…），DENSE_RANK() 不跳（1,2,2,3…）。选哪个取决于业务是否接受“并列但序号不连续”。
例如统计用户积分榜，若两人同分都算第 2 名，该用 RANK()；若要求名次严格连续（并列第 2 后就是第 3），就该用 DENSE_RANK()。用错会导致前端分页错位或排名展示异常：
-- 并列时 ROW_NUMBER 给不同序号（强制唯一） SELECT score, ROW_NUMBER() OVER (ORDER BY score DESC) FROM users; <p>-- 并列时 RANK 跳过后续序号 SELECT score, RANK() OVER (ORDER BY score DESC) FROM users;
WHERE 不能直接过滤 ROW_NUMBER() 别名，需嵌套查询
下面这句会报错：SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE rn ，因为 <code>WHERE 执行早于窗口函数计算。必须把带 ROW_NUMBER() 的查询包进子查询或 CTE，再对外层筛选：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM logs ) t WHERE t.rn BETWEEN 11 AND 20;
- 分页场景务必这么写，否则
LIMIT/OFFSET在无序表上行为不可靠 - CTE 写法更清晰：
WITH numbered AS (...) SELECT * FROM numbered WHERE rn > 10 - 注意：MySQL 8.0+、PostgreSQL、SQL Server 支持；旧版 MySQL 需用变量模拟，但并发下易出错
真正麻烦的是跨数据库兼容——SQLite 仅支持简单 OVER，Oracle 用 ROWNUM 但不支持 PARTITION BY，这些细节不提前确认，上线后容易卡在分页或排名逻辑上。
