窗口函数中order by必须确保排序确定性，否则结果不稳定；应追加唯一字段（如id）破除重复值平局，显式处理null，并避免与外层逻辑混淆。
ORDER BY 在窗口函数里没生效，结果每次都不一样
窗口函数的 ORDER BY 子句必须明确、可确定，否则数据库（尤其是 PostgreSQL、SQL Server）可能忽略它或返回非预期顺序。MySQL 8.0+ 虽强制要求排序，但若排序字段存在重复值且未加唯一性约束，结果仍不稳定。
- 根本原因是：当
ORDER BY列有重复值时，数据库没有义务保持相同输入下输出顺序一致——它只保证逻辑分组和累积计算正确，不保证“稳定排序” - 典型表现：
ROW_NUMBER() OVER (ORDER BY created_at)在created_at相同的多行间，每次查询编号顺序可能不同 - 解决办法不是加个
ORDER BY就完事，而是让它“可确定”：在排序列后追加主键或唯一标识字段
例如：ROW_NUMBER() OVER (ORDER BY created_at, id) —— 即使时间相同，id 能打破平局。
用 PARTITION BY + ORDER BY 时，分区边界被意外打乱
很多人以为只要写了 PARTITION BY category ORDER BY score，每个分类内就一定按 score 严格升序排列并编号。但实际中，如果 score 有 NULL 值，默认排序行为因数据库而异（PostgreSQL 把 NULL 排最后，MySQL 可能排最前），导致同一分区内的相对顺序不可控。
-
NULLS FIRST或NULLS LAST是显式控制手段，但并非所有数据库都支持（MySQL 8.0 不支持，PostgreSQL 支持） - 更通用的做法是把
NULL显式转为一个确定值，比如：ORDER BY COALESCE(score, -999999) - 如果业务上
score本不该为NULL，那就该在建表时加NOT NULL约束，而不是靠 SQL 补救
ORDER BY 多字段组合时，ASC/DESC 混用引发逻辑错位
写成 ORDER BY status ASC, updated_at DESC 看似合理，但如果后续想用这个排序结果做分页或取 top-N，就容易出问题：比如你想要“最新激活用户”，但 status = 'active' 的行太多，updated_at DESC 的排序只在 status 相同时才生效，而 status 本身是第一级排序——这意味着所有 inactive 用户会先被排在前面，完全不符合直觉。
- 窗口函数里的
ORDER BY是为计算服务的，不是为最终展示服务的；别把它和外层ORDER BY混为一谈 - 真正要“取最新激活用户”，应该在外层加
WHERE status = 'active'，再对子查询结果排序，而不是指望窗口函数内部排序“替你筛选” - 如果必须在窗口内体现优先级，可用表达式：比如
ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END, updated_at DESC
MySQL 8.0 中 ROW_NUMBER() 结果跳号或重复？
这不是 bug，而是你用了带 DISTINCT 或隐式去重的查询结构。MySQL 的窗口函数是在去重前计算的，但如果你在外面套了一层 SELECT DISTINCT，就会看到编号不连续甚至重复——因为 ROW_NUMBER() 已经算完了，DISTINCT 只是删行，不重编号。
- 错误写法：
SELECT DISTINCT name, ROW_NUMBER() OVER (ORDER BY score) AS rn FROM users - 正确做法：先用窗口函数生成编号，再在外层去重（如果真需要），或改用
GROUP BY+ 聚合逻辑 - 另一个常见陷阱：在
JOIN后直接开窗，若关联产生笛卡尔积，ROW_NUMBER()会为每条连接结果编号，而不是按原始主表行编号——得先GROUP BY或用EXISTS控制粒度
稳定性的关键不在语法多漂亮，而在每一级排序都有唯一锚点。漏掉一个 id，就可能让整个报表导出结果每天都不一样。
