row_number()结果不一致的根源是排序字段不唯一或分区逻辑误用。需确保order by含主键等唯一字段，partition by匹配业务粒度，where中rn须用子查询/cte引用，mysql 8.0.2以下需升级或慎用变量模拟。
ORDER BY字段重复导致编号随机
ROW_NUMBER()本身没坏，是它依赖的排序依据不够唯一。比如只写ORDER BY created_at，而表里有多个记录时间戳完全相同（高并发插入很常见），数据库就只能凭物理存储顺序或内存布局“猜”谁排前面——这次A行得1，下次B行得1。这不是bug，是SQL标准允许的未定义行为。
实操建议：
- 用SELECT COUNT(*) FROM t GROUP BY created_at HAVING COUNT(*) > 1快速查出重复程度
- 补一个能打破平局的字段，最稳的是主键：ORDER BY created_at DESC, id DESC
- 别依赖毫秒级时间戳：哪怕字段类型是TIMESTAMP(6)，应用层写入若没控制好时钟同步或事务提交顺序，仍可能撞车
- NULL值要显式处理，否则不同数据库对NULL = NULL判断不一致，例如改用ORDER BY COALESCE(created_at, '1970-01-01') DESC, id DESC
PARTITION BY后rn=1结果不唯一
这不是函数失效，是语义误解。只要写了PARTITION BY，ROW_NUMBER()就只保证“每个分区内从1开始连续编号”，不同分区的rn = 1完全合法。比如按user_id分组，两个用户各自最新一条记录都叫rn = 1，很正常。
但如果你拿这个rn = 1当全局去重条件，就会漏数据或重复取。
实操建议：
- 检查PARTITION BY字段的实际去重数：SELECT COUNT(DISTINCT user_id), COUNT(*) FROM t，如果两者接近，说明分组基本失效
- 避免用高基数字段（如UUID、主键）做分组依据；优先选业务上有明确聚合粒度的字段，如order_id、dept_id
- NULL参与分组时行为跨库不一致，显式转换：PARTITION BY COALESCE(user_id, -1)
WHERE里直接引用rn别名报错或逻辑错
错误信息类似Unknown column 'rn'或查不到数据，根本原因是SQL执行顺序：WHERE在窗口函数计算前就已执行，此时rn还不存在。
实操建议：
- 必须用子查询或CTE包裹：WITH ranked AS (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t) SELECT * FROM ranked WHERE rn = 1
- 别名别用rank、row_number这类保留字，某些方言（如旧版Hive）会解析冲突
- CTE比嵌套子查询更易读、更易调试，尤其多层窗口逻辑时
MySQL低版本根本不支持ROW_NUMBER()
FUNCTION xxx.ROW_NUMBER does not exist不是语法错，是版本硬限制。MySQL直到8.0.2才原生支持窗口函数，5.7或更早版本执行直接报错。
强行模拟（如用@rownum := @rownum + 1）风险很高：
- 并发查询下变量状态不可控，结果可能错乱
- 无法和ORDER BY严格绑定，排序和编号可能脱节
- 某些执行计划中变量初始化时机不确定，导致首行编号为NULL或0
真正让ROW_NUMBER()每次结果一致的关键，从来不是函数本身，而是你给它的排序组合是否能唯一确定每一行的位置——少一个id，就多一分不确定性。
