ROW_NUMBER()未按预期排序的根本原因是ORDER BY列存在重复值，导致数据库随机决定相同值行的编号顺序；必须补充唯一排序键（如主键）才能保证结果稳定可复现。
ROW_NUMBER() 为什么没按预期排序？
根本原因不是函数失效，而是 ORDER BY 子句中用于排序的列存在重复值，且你没意识到 ROW_NUMBER() 会“随机”决定这些重复行的先后顺序——它只保证唯一和连续，不保证可复现。
比如对两行 score = 85 的记录执行 ROW_NUMBER() OVER (ORDER BY score)，数据库可能这次给 A 行编 1、B 行编 2，下次却反过来。这不是 bug，是标准行为。
- 必须明确：只要
ORDER BY表达式不能唯一确定行序，ROW_NUMBER()的结果就不可预测 - 常见诱因：仅用
created_at（毫秒精度缺失）、status、category等低基数字段单独排序 - 修复方式不是换函数，而是补全排序键：加一个能打破平局的列，如主键
id或带更高精度的时间戳
PARTITION BY 后 ROW_NUMBER() 结果乱序？
分区逻辑写错，会导致分组内排序基准错位。例如本该按用户分组，却写了 PARTITION BY city，那每个城市的用户数据会被混在一起重新编号，结果自然失真。
-
PARTITION BY字段必须与业务语义严格对齐：查“每个部门最高薪员工”，就必须是PARTITION BY dept_id，不是dept_name（可能重名） - 多个字段组合分区时，注意 NULL 值处理：
PARTITION BY a, b中若某行a IS NULL AND b IS NULL，它会被归入同一组，但不同数据库对 NULL 相等性的判断略有差异 - MySQL 8.0+ 中，如果分区字段无索引，大表上
ROW_NUMBER()可能触发临时表 + 文件排序，性能骤降
WHERE 条件里直接用了 ROW_NUMBER() 别名？
会报错或返回空结果，因为窗口函数在 SQL 执行顺序中晚于 WHERE 阶段。别名在同级查询中不可见。
- 错误写法：
SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE rn = 1→ 报错Unknown column 'rn' - 正确做法只有两种：套子查询，或用 CTE；外部再过滤
- 别名命名要避免关键字冲突，比如别叫
rank（和RANK()函数同名），某些方言下可能引发解析歧义
MySQL 5.7 或更早版本跑不了 ROW_NUMBER()？
是的，原生不支持。它不是语法写错，是版本硬限制。强行运行会提示 FUNCTION xxx.ROW_NUMBER does not exist。
- 替代方案只能用变量模拟：
@rownum := @rownum + 1，但需配合ORDER BY和初始化，且在并发查询下不稳定 - 升级到 MySQL 8.0+ 是最稳妥解法；若无法升级，建议在应用层做分页或去重，避免在 SQL 层硬扛
- 注意：即使版本达标，也要确认 SQL mode 没禁用窗口函数（极少见，但某些云厂商托管实例会默认关闭）
真正容易被忽略的点是：排序列的“逻辑唯一性”比“物理唯一性”更重要。哪怕 id 是主键，如果你在 ORDER BY 里漏掉了它，仅靠业务字段排序，ROW_NUMBER() 就永远无法稳定输出。
