SQL窗口函数实战：用PARTITION BY实现成绩排名-代码聚汇网

SQL窗口函数实战：用PARTITION BY实现成绩排名

流浪小鱼·2026-08-29·阅读 22 GEO检测（免费）

SQL窗口函数PARTITION BY

|难度：普通|阅读约 10 分钟

做成绩排名这种需求，十个人里有八个会先想到 GROUP BY 加聚合函数，可真上了手才发现，想按班级排、按科目排、还要保留每个人原始记录，GROUP BY 一压就只剩组了，根本没法用。后来换成 MS SQL Server 里的 partition by，一行 OVER 子句解决所有问题，代码从几十行缩到几行，性能还更好。这篇就把我实际做成绩排名系统的经验完整拆开讲，包括 ROW_NUMBER、RANK、DENSE_RANK 这几个窗口函数的差异、真实场景里的写法、以及我踩过的坑，适合刚接触窗口函数的同学，也适合写了不少 SQL 但没用明白 partition by 的人。

1. 场景切入：为什么成绩排名必须用 partition by

1.1 传统排名写法的痛点

先看一个非常常见的需求：一张学生成绩表，里面有学生姓名、班级、科目、分数，现在要按班级给每个学生的语文成绩排名。不懂窗口函数的人，第一反应就是自连接：

sql复制SELECT a.student_name, a.class_id, a.score,
       (SELECT COUNT(*) + 1 
        FROM score b
        WHERE b.class_id = a.class_id
          AND b.subject = '语文'
          AND b.score > a.score) AS rank_num
FROM score a
WHERE a.subject = '语文'
ORDER BY a.class_id, rank_num;

这段 SQL 能跑，但问题很明显：子查询里每处理一行，就要扫描一遍整个表，成绩表一旦上了十万行，执行计划里全是嵌套循环，慢到你怀疑人生。而且如果分数相同，这个写法给出的名次是跳跃式的还是并列式的，需要额外加条件去判断，逻辑稍不留神就写错。

另外一个常见方案是 GROUP BY 班级后做聚合排名，但 GROUP BY 会把组内的明细行合并成一行，你最终只能得到每个班级最高分是多少，得不到“张三在班里排第几”这种带明细数据的排名。这就是 GROUP BY 的天然限制——它做的是“汇总”，不是“排名”。

1.2 窗口函数到底解决了什么问题

partition by 属于窗口函数（Window Function）的一部分，它解决问题的核心思路是：把表按某些列分成多个逻辑分组（也就是“窗口”），在每一个窗口内部独立执行计算，但计算完后每一行还是保留在原地，不会像 GROUP BY 那样折叠行数。

打个生活化的比方：GROUP BY 像是把一堆学生按班级分组后，每组只派一个代表出来讲话；而 partition by 像是每个班都发了一张记分表，每个人的成绩都留在表上，表后面多了一列“你在你们班排第几”。这种“既分组又不丢明细”的特性，正好是排名场景最需要的。

用 partition by 改写上面的需求，只需要一行：

sql复制SELECT student_name, class_id, subject, score,
       ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC) AS rank_num
FROM score
WHERE subject = '语文';

代码量断崖式下降，而且执行计划里只会出现一次排序操作（或一次索引扫描），性能比自连接高一个量级。这也是为什么在现代 SQL 开发里，窗口函数几乎是排名类需求的默认首选方案。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心函数逐个拆解：ROW_NUMBER、RANK、DENSE_RANK、NTILE

2.1 四个排名函数的作用对比

很多初学者一上来就被四个长得差不多的函数搞晕：ROW_NUMBER、RANK、DENSE_RANK、NTILE。它们都配合 OVER 使用，但在处理“并列值”时的行为完全不同。我直接做了一张对比表：

函数	基本作用	分数相同时的结果	典型应用场景
ROW_NUMBER()	生成连续的行号	并列时随机/按 ORDER BY 决定先后，名次不重复	分页、去重、取 Top N
RANK()	生成排名，并列占位	并列相同，后续名次跳过（如：1、2、2、4）	竞赛排名、体育比赛
DENSE_RANK()	生成密集排名	并列相同，后续名次不跳过（如：1、2、2、3）	奖学金等级、绩效档位
NTILE(n)	把数据尽量平均分成 n 组	按顺序切分，不看并列	百分位、成绩分段统计

这里最容易踩坑的是 RANK 和 DENSE_RANK 的区别。假设四个人分数分别是 98、95、95、92，RANK 的结果是 1、2、2、4，DENSE_RANK 的结果是 1、2、2、3。很多业务方口中的“并列第三”其实是 DENSE_RANK 的语义，而如果你用了 RANK，你会发现没有第三名，直接跳到第四名，这时候跟业务确认口径就非常重要。

2.2 函数选型的判断标准

我的经验是，拿需求文档的时候先问三个问题：

第一个问题，允许并列吗？如果业务上每个名次只能有一个人（比如“一等奖只有一个人”），那就必须用 ROW_NUMBER，哪怕两个人分数一样，也要给其中一个排前面，再配合 ORDER BY 后面的次排序键决定谁在前。

第二个问题，如果允许并列，后面的人要不要跳号？体育比赛常用 RANK，因为金牌、银牌、铜牌的数量是固定的，两个人并列第二，那第四名其实相当于下一批，用 RANK 语义更准确。而如果只是给用户看一个“等级”，不希望中间空着，就用 DENSE_RANK。

第三个问题，需不需要按比例分段？比如“成绩前 25% 为优秀，后 25% 为待提高”，这种不用算精确名次，直接 NTILE(4) 按四等分切就行。

2.3 OVER 子句的执行顺序逻辑

要真正理解这几个函数，还得知道 OVER 子句的底层执行顺序。SQL 语句的各个子句并不是按书写顺序执行的。对于带窗口函数的查询，实际执行顺序大致是：先 FROM 加载表，再 WHERE 过滤，再 GROUP BY 分组，然后 HAVING 过滤分组，接着窗口函数在这一步开始计算，最后才是 SELECT 投影和 ORDER BY 排序。

这个顺序解释了为什么窗口函数不能放在 WHERE 里面用。比如你想查“每个班级排名前三的学生”，你不能写 WHERE ROW_NUMBER() OVER (...) <= 3，因为窗口函数计算发生在 WHERE 之后，WHERE 阶段根本不知道这个值。正确做法是把窗口函数放在子查询或 CTE 里，先算出排名，再在外层过滤。

sql复制;WITH Ranked AS (
    SELECT student_name, class_id, score,
           ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC) AS rn
    FROM score
)
SELECT *
FROM Ranked
WHERE rn <= 3;

这个 CTE + 外层过滤的写法，是取“各组前 N 名”最标准的姿势，后面实战部分会反复用到。

3. 成绩排名实战：从建表到各类榜单完整落地

3.1 准备测试环境：建表与造数

工欲善其事，必先利其器。先建一张学生成绩表，模拟一个简化版的考试系统数据。我实际项目里的表结构通常还要多几个字段，比如考试批次、是否缺考，但为了演示清晰，我先保留最核心的字段。

sql复制CREATE TABLE score (
    id INT IDENTITY(1,1) PRIMARY KEY,
    student_name NVARCHAR(50) NOT NULL,
    class_id INT NOT NULL,
    subject NVARCHAR(20) NOT NULL,
    score DECIMAL(5,1) NOT NULL
);

INSERT INTO score (student_name, class_id, subject, score) VALUES
('张三', 1, '语文', 98.0),
('李四', 1, '语文', 95.0),
('王五', 1, '语文', 95.0),
('赵六', 1, '语文', 92.0),
('钱七', 2, '语文', 89.0),
('孙八', 2, '语文', 88.0),
('周九', 2, '语文', 91.0),
('吴十', 2, '语文', 99.0),
('张三', 1, '数学', 88.0),
('李四', 1, '数学', 92.5),
('王五', 1, '数学', 97.0),
('赵六', 1, '数学', 80.0),
('钱七', 2, '数学', 93.0),
('孙八', 2, '数学', 85.5),
('周九', 2, '数学', 79.0),
('吴十', 2, '数学', 90.0);

这里故意让“李四”和“王五”语文分数相同，就是为了演示并列排名的差异。造数的时候我有几个习惯：一是把小数不要弄成整数，DECIMAL(5,1) 更贴近真实成绩；二是故意制造重复分数，否则 RANK 和 DENSE_RANK 的差别根本看不出来。

3.2 全年级排名：不带 PARTITION BY 的写法

如果说 PARTITION BY 是“分组排名”，那不加 PARTITION BY 的全表排名就是“全体大排名”。比如年级组长想看语文单科全年级排名，SQL 很简单：

sql复制SELECT student_name, class_id, score,
       RANK() OVER (ORDER BY score DESC) AS grade_rank
FROM score
WHERE subject = '语文'
ORDER BY grade_rank;

这个时候 OVER 里只有 ORDER BY，没有 PARTITION BY，相当于把整张表当成一个大的窗口，所有人的成绩放在一起排序。结果里张三排第 1，李四和王五都是第 2，赵六第 4。

注意这里有个小细节：ORDER BY 默认是 ASC 升序，排名场景要明确写 DESC，否则就会变成分数越低排名越靠前。我见过不止一个同事把 DESC 漏掉，出来的榜单倒着排，还纳闷为什么第一名是 0 分。

3.3 按班级排名：PARITION BY 单字段

这是使用频率最高的场景——每个班内部排名。只需要在 PARTITION BY 后面指定班级字段，窗口就会按班级自动切分：

sql复制SELECT student_name, class_id, subject, score,
       DENSE_RANK() OVER (PARTITION BY class_id ORDER BY score DESC) AS class_rank
FROM score
WHERE subject = '语文'
ORDER BY class_id, class_rank;

PARTITION BY class_id 的意思是：先把所有语文成绩按 class_id 分成两个窗口，一班一个窗口、二班一个窗口，然后在每个窗口内部独立按分数排名。一班的第一名是 98 分，二班的第一名是 99 分，两个班的名次互不干扰，都是从 1 开始。

在实际报表系统里，这种按单个维度切分的写法最常见。但要注意的是，你的 SELECT 列表里如果还带了班级名称，最好从维度表关联，而不是在成绩表里直接把 class_id 显示出来给用户看，因为用户根本不知道 1、2 代表什么班。我在真实项目里通常这样写：

sql复制SELECT c.class_name, s.student_name, s.score,
       RANK() OVER (PARTITION BY s.class_id ORDER BY s.score DESC) AS rank_num
FROM score s
INNER JOIN class c ON s.class_id = c.class_id
WHERE s.subject = '语文';

3.4 按科目排名：PARTITION BY 多字段

接着升级需求：不只要按班级排，还要按班级 + 科目双维度排。比如班主任想看“本班同学每一科的名次”，那就要同时按班级和科目切窗口，PARTITION BY 后面跟多个字段用逗号分隔：

sql复制SELECT student_name, class_id, subject, score,
       ROW_NUMBER() OVER (PARTITION BY class_id, subject ORDER BY score DESC) AS subject_rank
FROM score
ORDER BY class_id, subject, subject_rank;

多字段 PARTITION BY 的理解方式可以类比为“复合分组”：先按 class_id 分，再按 subject 分，最终每个 (class_id, subject) 组合都是一个独立的窗口。上面的示例数据里，一班语文、一班数学、二班语文、二班数学，一共四个窗口，每个窗口内部都从 1 开始编号。

多字段 partition 在实际项目里非常实用，比如按“年、月、部门”统计业绩排名，按“城市、门店、品类”排畅销榜。它的性能比写多个子查询再 UNION 要好得多，因为整个语句只扫一遍表。

3.5 取每个班级前三名：CTE + ROW_NUMBER

理论上讲，前面在讲执行顺序时已经给出了“各组前 N 名”的写法，这里再用真实场景走一遍完整流程。业务需求是：每个班语文成绩的前三名，要进入光荣榜。此时优先选 ROW_NUMBER，因为一个榜位只能有一个人，即使并列也要选出一个来。

sql复制;WITH Ranked AS (
    SELECT student_name, class_id, score,
           ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC, id ASC) AS rn
    FROM score
    WHERE subject = '语文'
)
SELECT student_name, class_id, score, rn
FROM Ranked
WHERE rn <= 3
ORDER BY class_id, rn;

第二行里我故意在 ORDER BY 后面多写了一个 id ASC，这是处理“分数相同但只能取一人”的关键技巧。当分数相同时，ROW_NUMBER 并不保证先后顺序，如果你不指定次排序键，同一个查询结果可能出现一会儿李四在前、一会儿王五在前的不稳定现象。加上 id 作为 tie-breaker，就能保证每次跑结果一致。

3.6 计算班级平均排名与分位数：NTILE 应用

还有一个我经常在教学质量分析里用到的场景：不只看精确名次，还要知道学生大致处于班级的哪个位置，比如前 25%、中间 50%、后 25%。这时候 NTILE(4) 的分段逻辑比算半天百分比更直接：

sql复制SELECT student_name, class_id, score,
       NTILE(4) OVER (PARTITION BY class_id ORDER BY score DESC) AS quartile
FROM score
WHERE subject = '语文'
ORDER BY class_id, quartile;

NTILE 返回 1 到 4 的值，1 表示该窗口内分数最高的四分之一，4 表示最低的四分之一。它跟 RANK 系列的区别在于，它不看分数是否并列，而是按行数硬切。如果某个班有 5 个人，切 4 份的结果是 2、1、1、1，前三名中分数并列第二的人可能被分到不同档位，这在给老师做教学建议时会有争议，所以用 NTILE 之前一定确认业务上是否接受“硬切”的逻辑。

4. partition by 与 group by 的混淆点及高频报错排查

4.1 partition by 和 group by 的本质区别

如果把这个问题拍给十个 SQL 开发，至少有三四个会懵一会儿。GROUP BY 把多行折叠成一行，让你只能看到聚合结果；PARTITION BY 保留所有行，同时附加聚合或排名结果。这两者的差异决定了它们不能互换。

举一个例子，你要统计每个班级的总分：

sql复制-- GROUP BY 写法：每个班一行
SELECT class_id, SUM(score) AS total_score
FROM score
GROUP BY class_id;

-- PARTITION BY 写法：每一行后面多一列总分
SELECT student_name, class_id, score,
       SUM(score) OVER (PARTITION BY class_id) AS class_total
FROM score;

第二个查询的效果是，每个学生的行都能看到自己班级的总分，这一列在班里所有人身上是重复的。这在做“分数占总分比例”“分数离班级平均分差多少”这类明细+汇总混排的报表时特别有用。

4.2 窗口函数中 ORDER BY 与 TOP 的配合误区

窗口函数算完排名后，很多初学者会顺手写 TOP 3 去取前三，这个思路没问题，但要注意 TOP 和 ORDER BY 的配合。如果你写成：

sql复制SELECT TOP 3 student_name, class_id, score,
       ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC) AS rn
FROM score
WHERE subject = '语文';

这会得到全表前三行，而不是每个班前三名。因为 TOP 是对最终结果集取前 3 条，窗口函数是按班级分别编号，两者逻辑根本对不上。正确姿势还是用 CTE 或子查询，先计算出 rn，再在外层 WHERE rn <= 3。

4.3 常见报错：无法将 "sqlcmd" 识别为 cmdlet、函数、脚本文件

这里插一个实际环境里高频出现的问题，很多人在自己电脑上写完 SQL，想用命令行工具跑一下测试，结果一敲 sqlcmd 就报“无法将‘sqlcmd’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个问题本质是环境变量没配好，Windows 找不到 sqlcmd.exe 的路径。跟窗口函数本身无关，但它会卡住你整个调试流程。

解决办法有三种：

完整路径调用，比如 C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\SQLCMD.EXE -S localhost -E。
把 sqlcmd 所在目录加到系统环境变量 PATH 里，一劳永逸。
直接不用命令行，用 SSMS 或 Azure Data Studio 跑测试，图形界面在调试窗口函数时反而更直观，能看到每一列的结果。

4.4 排名结果不稳定：缺少 tie-breaker 导致的问题

另一个高频排查项是“同样的数据，跑两次排名结果不一样”。大部分情况下都出在 ROW_NUMBER 没有足够的 ORDER BY 列。SQL Server 不保证无唯一排序时行号的分配顺序，也就是说当两行分数一样，又没有指定别的排序键，数据库按物理存储顺序取，而物理存储顺序可能因为索引重建、碎片整理而变化。解决办法就是在 ORDER BY 里补上唯一键，比如 id，让排序结果完全确定。

5. 性能优化与避开窗口函数的常见陷阱

5.1 索引怎么建才有效

说句实话，窗口函数并不总能走索引，它经常触发排序操作。你要想优化排名查询，重点不是加多少索引，而是让排序尽量少发生。对于 PARTITION BY class_id ORDER BY score DESC 这种写法，最理想的索引是复合索引，并且列的顺序要与 PARTITION BY 和 ORDER BY 的字段顺序一致：

sql复制CREATE INDEX idx_class_score ON score(class_id, score DESC);

这个索引能让 SQL Server 按班级顺序扫描，并且在每个班级内部已经按分数排好序，这样排序运算符可能直接被省略掉，执行计划更快。如果你的查询里还有 WHERE subject = '语文'，可以考虑把 subject 也加进索引，或者放在最前面做过滤列：

sql复制CREATE INDEX idx_subject_class_score ON score(subject, class_id, score DESC);

索引设计没有银弹，我的习惯是先用执行计划看有没有 Sort 运算符，如果有，再根据实际谓词组合去微调索引。

5.2 大表上排名查询的常见性能陷阱

窗口函数本质是“先排序、后计算”，所以数据量大了以后，最怕的是在 WHERE 条件没过滤掉足够多数据的情况下直接对全表做排名。比如一张一千万行的成绩表，你只查语文成绩，却因为忘了加 WHERE subject 条件，导致 SQL Server 对全表按 (class_id, subject, score) 排序，排序开销直接翻好几倍。

除此之外，也尽量避免在窗口函数的 PARTITION BY 里写计算列或函数，比如 PARTITION BY YEAR(create_time)，这不仅让索引失效，还会导致额外的计算开销。如果确实要按年月排名，通常的做法是先在基础表上增加一个年月的持久化计算列，再对这个列建索引，这样查询性能会稳定很多。

5.3 不要滥用窗口函数

窗口函数很强大，但并不是所有场景都用它才显专业。如果你的需求只是简单的“每个班总分最高的人是谁”，用 GROUP BY 加 JOIN 反而更容易理解；如果你要的是“每个班总分的明细加总”，那用 GROUP BY 搭配窗口函数一起使用才是正解。我见过有人写出一个查询里套了五层窗口函数，逻辑复杂到根本没法维护，那就是过度设计了。窗口函数是用来解决“明细行上做聚合/排名”这类特定问题的，场景对了再用。

6. 实操心得与延伸技巧

6.1 一个排名加占比的复合报表写法

排名经常不只是单独一列，而是和占比、累计值一起出现在报表里。比如班主任要一张表，里面同时有学生各科分数、单科班级排名、该科班级平均分、以及该生分数占班级总分的比例。这种需求用窗口函数写起来非常舒服：

sql复制SELECT student_name, class_id, subject, score,
       RANK() OVER (PARTITION BY class_id, subject ORDER BY score DESC) AS rn,
       AVG(score) OVER (PARTITION BY class_id, subject) AS avg_score,
       SUM(score) OVER (PARTITION BY class_id, subject) AS total_score,
       CAST(score * 100.0 / SUM(score) OVER (PARTITION BY class_id, subject) AS DECIMAL(5,2)) AS pct_of_total
FROM score
ORDER BY class_id, subject, rn;

这段 SQL 里 PARTITION BY 用的是同一组字段 (class_id, subject)，所以三个窗口函数共享同一套窗口定义，代码既简洁又不冗余。如果你想更懒一点，SQL Server 还支持 WINDOW 子句把窗口定义抽出来命名，在 2022 版本里已经可用，不过老版本不支持，项目要兼容 SQL Server 2019 及以下的话还是老老实实写完整 OVER 子句。

6.2 用 ROW_NUMBER 做数据去重

除了排名，ROW_NUMBER 还有一个高频用途是“分组去重”。比如成绩表里因为系统 bug 插入了重复记录，同一个学生、同一科目、同一考试批次出现了两行，你要保留其中一行，就可以：

sql复制;WITH Duplicated AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY student_name, subject, exam_batch ORDER BY id ASC) AS rn
    FROM score
)
DELETE FROM Duplicated WHERE rn > 1;

这里的 PARTITION BY 定义了“什么是重复”的组合键，ORDER BY id ASC 则决定保留最小 id 的那一行。这种写法比传统 NOT EXISTS 去重要清晰得多，尤其对多列重复键判断非常友好。但执行 DELETE 之前一定在事务里先 SELECT 出来确认 rn 的分布，避免误删。

6.3 建议先写小结果集验证，再上生产

最后分享一个我自己的习惯：任何排名查询上线前，我都会先造一组包含并列分数的测试数据，分别跑一遍 ROW_NUMBER、RANK、DENSE_RANK、NTILE，把结果放进 Excel 里人工核对一遍。不是因为不信任 SQL 引擎，而是因为业务口径的歧义只有在这种并列样本里才会暴露——你永远不知道产品经理说的“并列第三”是 RANK 语义还是 DENSE_RANK 语义。

另外，窗口函数的结果集比普通查询更依赖数据的排序稳定性，所以上线后要定期关注索引碎片。如果表和索引的物理顺序变化导致排名结果抖动，那不是 SQL 写错了，而是排序依赖没兜住。给 ORDER BY 补上唯一键之后，这类问题基本就不会再出现了。