row_number() 在分组后“乱序”是因为它仅按窗口内 order by 排序编号，若未指定或排序字段重复则结果不稳定；应显式添加确定性排序字段如 id 或 created_at，并依业务需求选用 rank() 或 dense_rank()。
ROW_NUMBER() 为什么总在分组后“乱序”
因为 ROW_NUMBER() 本身不保证全局顺序，只按 ORDER BY 子句在当前窗口内编号。如果你没写 ORDER BY，或者 ORDER BY 字段存在大量重复值，编号就看似“随机”。
常见错误现象：select id, ROW_NUMBER() OVER (PARTITION BY category ORDER BY id) FROM t 返回的序号在同 category 内跳变——其实是 id 有重复或索引缺失导致排序不稳定。
- 必须显式指定确定性排序字段，比如加
id或created_at作二级排序：ORDER BY status, id - 如果业务上允许并列，别硬用
ROW_NUMBER()，该换RANK()或DENSE_RANK() - mysql 8.0+ 和 postgresql 支持窗口函数，但 sqlite 3.25+ 才开始支持，旧版会直接报错
near "OVER": syntax Error
RANK() 和 DENSE_RANK() 的并列处理差异
三者都处理“相同值怎么排号”，但策略不同：RANK() 跳号，DENSE_RANK() 不跳，ROW_NUMBER() 强制不并列。
使用场景：排行榜里“第1名有两个，下一个应该是第2名还是第3名？”——这就是 DENSE_RANK() 和 RANK() 的分水岭。
-
RANK()：两个并列第1，下一个就是第3（跳过2）；适合强调“名次层级” -
DENSE_RANK()：两个并列第1，下一个就是第2；适合展示“实际位次” - 示例：
SELECT score, RANK() OVER (ORDER BY score DESC) r, DENSE_RANK() OVER (ORDER BY score DESC) d FROM scores，当 scores = [100,100,90] 时，r 是 [1,1,3]，d 是 [1,1,2]
用 RANK() 实现“每组 Top N”却漏数据？检查 PARTITION 和 ORDER BY 是否匹配
典型写法是 WHERE rn 配合 <code>ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)，但漏数据往往不是逻辑错，而是分区键和排序依据没对齐。
常见错误现象：某 group 明明有 5 条记录，结果只返回 2 条；或者不同 group 的 Top 3 数量不一致。
- 确认
PARTITION BY字段是否真能唯一标识“组”，比如用user_id却忘了 NULL 值被归为同一组 -
ORDER BY必须包含足够区分度的字段，否则窗口内排序不确定，ROW_NUMBER()可能任意分配前 N - PostgreSQL 中若排序字段无索引，大表上
OVER (PARTITION BY x ORDER BY y)性能可能骤降；建议在(x, y)上建复合索引
SQL Server 里 RANK() 在视图中失效？注意兼容级别和 ORDER BY 位置
SQL Server 2012+ 支持窗口函数，但如果你的数据库兼容级别是 100（对应 SQL Server 2008），即使语法正确也会报错 Incorrect syntax near 'OVER'。
另一个隐形坑：在视图定义里用了 RANK()，但外部查询又加了 ORDER BY，结果序号看起来“错乱”——因为窗口函数计算早于最终排序。
- 检查兼容级别：
SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME()，低于 110 就得升级 - 视图中用
RANK()没问题，但别指望它控制最终结果集顺序；如需稳定输出，外部查询仍要写ORDER BY - SQL Server 对
ORDER BY子句要求更严：窗口函数里的ORDER BY不能引用别名，必须用原始列名或序号
事情说清了就结束。窗口函数不是黑盒，真正卡住你的，往往是排序字段的确定性、分区边界的清晰度，还有那几个容易被忽略的兼容性开关。