ROW_NUMBER() 是窗口函数，必须配合 OVER() 使用，否则报错；正确用法为 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)，其中 ORDER BY 必须存在且建议含唯一字段以保证稳定性。
ROW_NUMBER() 必须配合 OVER() 使用，否则直接报错
单独写 ROW_NUMBER() 会触发语法错误，比如 PostgreSQL 报 function row_number() does not exist，MySQL 8.0+ 报 ERROR 1064。它不是普通函数，而是窗口函数，必须带 OVER 子句定义分区和排序逻辑。
常见错误写法：SELECT id, ROW_NUMBER() FROM orders; —— 这行不通。
正确结构是：ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)，其中 PARTITION BY 可选，ORDER BY 在窗口内必须存在（否则数据库无法确定“第几行”）。
按用户分组、按时间升序生成序号的写法
典型场景：每个用户（user_id）下的订单，按创建时间 created_at 从早到晚编号，序号从 1 开始重新计数。
-
PARTITION BY user_id划定分组边界 -
ORDER BY created_at ASC确保时间越早序号越小；省略ASC默认也是升序，但显式写出更安全 - 注意：如果
created_at有重复值，序号仍会严格递增（窗口函数不保证“并列”，跟RANK()不同）
示例语句：
SELECT user_id, order_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS rn
FROM orders;
ORDER BY 里混用多个字段可能引发隐性排序冲突
当时间字段精度不足（如只存到天），或业务上允许同一时间多条记录时，仅靠 created_at 排序会导致结果不稳定 —— 每次查询 rn 值可能不同（尤其在 PostgreSQL 或 SQL Server 中）。
解决办法是在 ORDER BY 后追加唯一字段兜底：
- 优先用主键，如
ORDER BY created_at, id - 若主键无序或不可用，可用
ORDER BY created_at, order_id - 避免用
ORDER BY created_at, RAND()—— 破坏可重现性，调试困难
稳定写法示例：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at, id)
MySQL 5.7 不支持 ROW_NUMBER()，得换思路
如果你连 ROW_NUMBER() 都执行不了，大概率是 MySQL 版本低于 8.0。这时候不能硬套语法，得用变量模拟：
- 先按分组和时间排序：
ORDER BY user_id, created_at, id - 用用户变量维护分组内计数：
@rn := IF(@prev = user_id, @rn + 1, 1) - 必须同时用
@prev := user_id更新上一分组标识，顺序不能颠倒 - 变量方式在高并发或复杂 JOIN 下容易出错，且 MySQL 8.0+ 已弃用变量赋值的确定性保证
临时兼容写法（仅限测试/低负载）：
SELECT user_id, order_id, created_at,
@rn := IF(@prev = user_id, @rn + 1, 1) AS rn,
@prev := user_id
FROM orders
CROSS JOIN (SELECT @rn := 0, @prev := NULL) AS _init
ORDER BY user_id, created_at, order_id;
真正上线前，版本升级或改用 CTE + 窗口函数是更可靠的选择。
实际用的时候，最容易被忽略的是 ORDER BY 的稳定性 —— 时间字段重复却不加二级排序，会让自增序号在不同执行间漂移，查问题时很难复现。
