ROW_NUMBER()行号乱序主因是ORDER BY字段重复或PARTITION BY语义误解；需确保排序列组合唯一、慎用NULL、避免低版本MySQL，并通过子查询引用rn别名。
ORDER BY字段重复导致行号乱序
ROW_NUMBER()本身没坏，只是你给它的排序依据不够“说话算数”。比如只写 ORDER BY created_at，而表里有 3 条记录时间戳完全一样（尤其高并发插入时），数据库就只能凭运气排——这次 A 行得 1，下次可能 B 行得 1。这不是 bug，是 SQL 标准允许的未定义行为。
实操建议：
- 用
SELECT COUNT(*) FROM t GROUP BY <你的排序列> 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) - 真需要全局唯一序号，去掉
PARTITION BY，并确保ORDER BY组合唯一
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 5.7 或更早版本提示 FUNCTION xxx.ROW_NUMBER does not exist
不是语法错，是版本硬限制。MySQL 直到 8.0.2 才原生支持窗口函数，低版本执行直接报错。
实操建议：
- 升级到 MySQL 8.0+ 是唯一稳妥解法；若无法升级，别用
@rownum := @rownum + 1模拟——并发查询下变量状态不可控，结果大概率错乱 - 把分页或排名逻辑移到应用层处理，SQL 只负责取原始数据
- 确认云厂商托管实例是否禁用了窗口函数（极少见，但某些 RDS 默认关闭）
稳定不是靠函数“更聪明”，而是靠你写的 ORDER BY 足够明确——它得能一对一映射到每一行物理记录。最容易被忽略的，其实是那个你以为“肯定唯一”的时间字段，在真实生产环境里往往最先崩。
