row_number()不能单独使用，因其是窗口函数，必须配合over()子句明确指定order by（必需）和可选的partition by，否则sql引擎无法确定排序与分组逻辑，直接报“window function requires over clause”错误。
ROW_NUMBER() 必须配合 OVER() 使用，否则直接报错 Window function requires OVER clause
为什么 ROW_NUMBER() 不能单独写？
它是个窗口函数，不是普通标量函数，SQL 引擎需要明确知道“按什么分组、按什么排序”才能编号。漏掉 OVER() 或里面没写 ORDER BY，MySQL/PostgreSQL/SQL Server 都会拒绝执行。
常见错误写法：SELECT ROW_NUMBER(), name FROM users; → 直接报错
正确骨架是：ROW_NUMBER() OVER (ORDER BY ...)，ORDER BY 是强制的（哪怕你只是想按插入顺序排，也得选个字段）
如何保证行号从 1 开始连续不跳？
只要 OVER() 里没写 PARTITION BY，且 ORDER BY 字段无重复值或重复时有次级排序，就能得到 1,2,3,… 的自然序号。
但要注意这些坑：
- 如果
ORDER BY字段有重复值（比如多个用户created_at完全相同），不同数据库行为不一致：PostgreSQL 可能随机打乱顺序，导致每次查询行号不固定；SQL Server 和 MySQL 8.0+ 会按内部物理顺序补位，但不可靠 - 想绝对稳定？加一个唯一字段兜底，例如：
ROW_NUMBER() OVER (ORDER BY created_at, id) - 用
SELECT *套子查询再编号，比在复杂 JOIN 后直接编号更可控，避免因关联放大导致行号重复计算
和 RANK()、DENSE_RANK() 有什么区别？
三者都依赖 OVER()，但处理并列逻辑完全不同：
ROW_NUMBER()：严格递增，1,2,3,4 —— 即使值相同也绝不重复
RANK()：值相同时给相同名次，但跳过后续名次，比如 1,2,2,4
DENSE_RANK()：值相同时给相同名次，不跳号，比如 1,2,2,3
所以“生成连续行号”这个需求，只能选 ROW_NUMBER()；用错函数会导致分页错位或去重逻辑异常
实际分页场景怎么安全加行号？
不要在应用层拼 LIMIT/OFFSET 后再编号，而应在数据库内先编号再过滤，否则可能漏数据或重复。
示例（取第 2 页，每页 10 条）：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM orders ) t WHERE rn BETWEEN 11 AND 20;
注意点：
- 子查询必须有别名（如
t），否则 MySQL 会报Every derived table must have its own alias - ORDER BY 字段最好带索引，否则大表上
ROW_NUMBER()会触发全表排序，性能骤降 - 如果只是要“当前结果集的序号”，别在最外层 SELECT 再套一次
ROW_NUMBER()，那会重新计算，和预期不符
真正麻烦的是跨多表关联后还要编号——这时候 ORDER BY 字段的来源容易混淆，一不留神就用了未参与 JOIN 的字段，或者 NULL 值干扰排序稳定性。动手前先 EXPLAIN 看执行计划，确认排序是否走索引、是否触发临时表。
