窗口函数ORDER BY结果不稳定的根本原因是排序字段存在重复值，必须在ORDER BY后追加唯一字段（如id）打破平局，并注意NULL处理、索引匹配及rn别名不可在WHERE中直接使用。
窗口函数ORDER BY结果每次都不一样，怎么 fix？
根本原因是排序字段存在重复值，数据库不保证相同值的行之间顺序稳定。ROW_NUMBER() OVER (ORDER BY created_at)在created_at相同的多行间，编号可能每次查询都不同。
必须让每行在排序序列中有唯一位置，不能依赖数据库默认行为：
- 在ORDER BY后追加唯一字段，例如
ORDER BY created_at DESC, id DESC——id打破平局，方向要与业务逻辑一致（如“最新时间+同时间取最大ID”） - 避免用表达式包裹排序字段，比如
ORDER BY DATE(created_at), id会让索引失效，且DATE()本身不保证稳定性 - 如果排序字段含
NULL，不同数据库默认处理不同（PostgreSQL排最前，MySQL可能排最后），显式写NULLS LAST或用COALESCE(score, -999999)转为确定值
MySQL 8.0+里ROW_NUMBER()跳号或重复，是不是bug？
不是bug，是排序不稳定的典型表现。MySQL 8.0强制要求窗口函数带ORDER BY，但若该ORDER BY列有重复值且无第二字段兜底，结果仍不可靠。
常见错误写法：ROW_NUMBER() OVER (ORDER BY status)——status只有几个枚举值，大量重复，编号必然浮动。
正确做法：
- 补上唯一决胜字段：
ROW_NUMBER() OVER (ORDER BY status, id) - 业务逻辑优先级要用表达式体现，比如“激活用户优先”，写成
ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END, updated_at DESC - 别指望窗口内排序替你筛选数据；真要取“最新激活用户”，应在外部加
WHERE status = 'active'再开窗
为什么加了(created_at DESC, id DESC)索引还慢？
索引建了≠被用上。执行计划里key显示NULL或不是预期索引名，大概率是以下三件事没做对：
-
WHERE条件字段没进联合索引：比如查询带WHERE category = 'A'，但索引只建在(created_at, id)，数据库可能弃用该索引 - 类型不匹配：表字段是
TIMESTAMP，索引却建在DATETIME上，隐式转换导致索引失效 - 排序方向与索引方向不一致：索引是
(created_at ASC, id ASC)，但ORDER BY created_at DESC, id DESC无法复用，需重建对应方向的索引
别在WHERE里直接引用rn别名
ROW_NUMBER()生成的别名属于投影阶段，在SQL执行顺序中晚于WHERE，所以WHERE rn BETWEEN 1 AND 10一定报错Invalid column name 'rn'。
只有两种合法写法：
- 套子查询：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn FROM t) t2 WHERE t2.rn BETWEEN 1 AND 10 - 用CTE：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t) SELECT * FROM ranked WHERE rn BETWEEN 1 AND 10
别试HAVING或ORDER BY rn绕过——HAVING只作用于GROUP BY结果，ORDER BY只是最终排序，不影响筛选逻辑。
