row_number() 必须用多个独立窗口函数实现多维度排名,每个绑定不同的 partition by 和 order by;它不支持并列排名,应改用 rank() 或 dense_rank()。

ROW_NUMBER() 不能直接“应用多个子句”,必须用多个独立的窗口函数
SQL 不允许在一个 ROW_NUMBER() 函数里写多个 ORDER BY 或嵌套多个排序逻辑。所谓“多个排名”,本质是并列调用多个 ROW_NUMBER(),每个绑定不同的 PARTITION BY 和 ORDER BY。常见错误是试图这样写:ROW_NUMBER() OVER (ORDER BY score DESC, time ASC) AS rank1, ROW_NUMBER() OVER (ORDER BY time ASC) AS rank2 —— 这语法完全合法,但容易忽略它们彼此独立、互不影响,不是“子句”关系。
- 每个
ROW_NUMBER()是一个完整窗口计算,可单独控制分区与排序 - 同一 SELECT 中可同时存在 5 个甚至更多不同配置的
ROW_NUMBER(),只要别名不重复 - 数据库不会自动“合并”或“联动”这些排名;比如按分数排第1的人,按耗时排可能是第17名,这完全正常
按部门分组排名 + 全局排名必须分开写两个 ROW_NUMBER()
这是最典型多维度排名场景:既要看出员工在本部门内的相对位置,又要知道在整个公司中的绝对位置。两者逻辑隔离,必须拆成两个计算字段。
SELECT name, dept, score, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY score DESC) AS dept_rank, ROW_NUMBER() OVER (ORDER BY score DESC) AS global_rank FROM employees;
-
PARTITION BY dept是部门内重置计数的关键,漏掉就变成全局连续编号 - 两个
ORDER BY都用DESC是为了分数越高排名越靠前;若混用(如一个DESC一个ASC),需确认业务含义是否真要“高分优先”和“早入职优先”并存 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 均支持;SQLite 3.25+ 也支持,但旧版不支持窗口函数
避免用 ROW_NUMBER() 实现“并列排名”,该用 RANK() 或 DENSE_RANK()
很多人想用 ROW_NUMBER() 实现“同分同名次”,结果写出错误逻辑:比如两人同为 95 分,ROW_NUMBER() 一定返回 1 和 2,不可能返回 1 和 1。这不是 bug,是设计如此。
- 需要跳过后续名次(95 分→第1名,94 分→第3名):用
RANK() - 需要紧凑名次(95 分→第1名,94 分→第2名):用
DENSE_RANK() -
ROW_NUMBER()只适合严格唯一序号场景,例如“按时间戳生成插入顺序号”“分页取第 N 条” - 强行用
ROW_NUMBER()模拟并列排名,需配合自连接或 LAG/LEAD 判断值变化,复杂且低效
性能隐患:多个窗口函数会各自扫描数据,大表慎用
每个 ROW_NUMBER() 都触发一次窗口计算,即使 PARTITION BY 和 ORDER BY 完全相同,数据库通常也不会复用中间结果(极少数优化器可能合并,但不可依赖)。
- 对千万级表,写 4 个不同配置的
ROW_NUMBER(),可能比单个慢 3–4 倍 - 确保涉及的排序字段(如
score、created_at)上有索引,尤其当ORDER BY无PARTITION BY时,相当于全局排序 - 如果只是临时分析,可先用
WHERE过滤出小结果集再算排名;生产 SQL 中应评估是否真需实时计算,还是可预计算存到冗余字段
真正麻烦的不是语法写法,而是想清楚“每个排名到底服务于什么决策”——是给运营看部门对比?给风控做异常耗时预警?还是导出报表强制要求“同分同名次”?没想清这点,光堆 ROW_NUMBER() 只会让逻辑越来越难维护。










