ROW_NUMBER()未按预期排序的根本原因是ORDER BY列存在重复值，导致数据库随机决定相同值行的编号顺序；必须补充唯一排序键（如主键）才能保证结果稳定可复现。
ORDER BY列重复导致编号乱序
ROW_NUMBER() 本身没失效，是 ORDER BY 列值不唯一，让数据库在相同值之间“随便排”，每次执行结果可能不同。比如用 status 或 created_at（毫秒精度丢失）单独排序，两行都是 status = 'active'，谁先谁后没保证。
这种现象不是 bug，是 SQL 标准行为：窗口函数只保证编号唯一连续，不保证可复现，除非排序依据能唯一确定行序。
- 检查执行计划里是否出现
Sort节点 + 大量tempdbspill（SQL Server）或Using temporary; Using filesort（MySQL） - 用
COUNT(*)配合GROUP BY快速验证重复程度：SELECT status, COUNT(*) FROM t GROUP BY status HAVING COUNT(*) > 1 - 补一个能打破平局的字段，最常用的是主键或带更高精度的时间戳，例如：
ORDER BY created_at DESC, id DESC
WHERE 中直接引用 ROW_NUMBER() 别名报错
错误信息类似 Invalid column name 'rn' 或 Unknown column 'rn'，根本原因是 SQL 执行顺序中，WHERE 在窗口函数计算之前就已执行，别名此时还不存在。
不能写：SELECT ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t WHERE rn = 1
- 必须用子查询包裹：把窗口函数放在内层 SELECT，
WHERE放在外层 - 更推荐 CTE 写法，逻辑清晰不易出错：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t) SELECT * FROM ranked WHERE rn = 1 - 别名避免用
rank、row_number这类保留字，某些方言下会触发解析歧义
PARTITION BY 分组后每行 rn 都是 1
这说明 PARTITION BY 字段组合实际每行都不同，相当于“每行一个分区”。常见于误用高基数字段，比如用主键、UUID 或未处理 NULL 的表达式做分组。
例如：PARTITION BY CASE WHEN a IS NULL THEN b ELSE a END，若 a 和 b 各自几乎都唯一，那这个表达式也基本唯一。
- 用
SELECT COUNT(DISTINCT ...)检查分组字段的实际去重数，对比总行数 - 优先用业务语义明确的低基数字段，如
user_id、dept_id，而不是dept_name（可能重名） - NULL 值需显式处理，
NVL(col, -1)或COALESCE(col, 'unknown')比直接参与分组更可控
MySQL 5.7 或更早版本提示 FUNCTION xxx.ROW_NUMBER does not exist
这不是写错语法，是版本硬限制。MySQL 直到 8.0.2 才原生支持窗口函数，低版本执行会直接报错。
强行模拟（如用 @rownum := @rownum + 1）风险很高：并发查询下变量状态不可控，结果可能错乱，且无法和 PARTITION BY 对齐。
- 升级到 MySQL 8.0+ 是唯一稳妥解法
- 若无法升级，分页类需求改用
LIMIT offset, size+ 应用层缓存；取 Top N 类需求改用关联子查询或应用层聚合 - 检查云厂商托管实例是否默认禁用了窗口函数（极少见，但某些 RDS 配置会关掉）
真正卡住人的地方往往不在函数怎么写，而在你没意识到 ORDER BY 是否真能定序——哪怕只差一个主键字段，结果就可能从“稳定”变成“每次都不一样”。
