陆拾贰號1. 为什么窗口函数能彻底改变成绩排名方式？
算成绩排名这件事，几乎是所有带考试、带评分体系的系统里最刚需的功能。以前没有窗口函数的时候，大家在 SQL Server 里写排名，翻来覆去就是三条路：相关子查询、自连接、临时表配 IDENTITY 列。这三条路我都走过，说实话每条都不省心，数据量一旦上去，性能就开始摆烂。
相关子查询的写法，最典型的是这样：
sql复制SELECT
StudentID,
Score,
(SELECT COUNT(DISTINCT Score) + 1
FROM ScoreTable AS t2
WHERE t2.Score > t1.Score) AS Rank
FROM ScoreTable AS t1
ORDER BY Rank;
数据少的时候还能看，一旦成绩表到了十万行、百万行，这种写法基本就是在给数据库上刑——每一行都要去扫描一遍整张表，复杂度直接就是 O(n²)。我当时在做一个市级的统考分析系统，成绩数据五十多万行，这种查询跑一次要三四十秒，业务方天天催，后来实在顶不住才下决心全部重构成窗口函数。
窗口函数带来的核心转变，是从“逐行处理”变成了“整体分区处理”。通俗点说，以前的 SQL 写法像是一个人去银行排队办业务，每办一笔都要重新取一次号；窗口函数则是一下子把整个大厅的人按窗口分好队，然后每个窗口依次叫号，效率完全不是一个级别。
PARTITION BY 这件事，拿生活里的场景来类比，最贴切的就是分考场。一张成绩单光看分数是全年级混排的，但你按班级分组之后，每个班自己内部再排一次名，互不干扰。PARTITION BY 的作用就是这个——它把整个结果集按某个（或某几个）列拆成若干个独立的“小区间”，窗口函数只在每个小区间内部做运算。
而配合它一起用的 ORDER BY，则是在每个小区间内部再指定一个排序规则，决定“窗口”里的数据按什么顺序往前滚。这两者的配合关系，是整个窗口函数体系里最核心的底层逻辑，后面所有实战都会围绕这个来展开。
我在实际项目里最常用的三个排名函数——ROW_NUMBER()、RANK()、DENSE_RANK()——它们的语法骨架几乎一模一样：
sql复制ROW_NUMBER() OVER (PARTITION BY 分组列 ORDER BY 排序列)
RANK() OVER (PARTITION BY 分组列 ORDER BY 排序列)
DENSE_RANK() OVER (PARTITION BY 分组列 ORDER BY 排序列)
区别只在于对“并列名次”的处理方式不同。这一点不搞清楚，后面做成绩排名一定会翻车，因为业务方要的“名次”可能是三种完全不同的口径。下面我专门用一节来把这三个函数掰开揉碎地讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心技术拆解：ROW_NUMBER()、RANK()、DENSE_RANK() 怎么选？
2.1 三个函数的执行逻辑与对比
先看它们的定义。ROWNUMBER() 最简单粗暴——它给每一行分配一个从 1 开始的连续整数，不管有没有并列，都不会出现重复的序号。也就是说，如果两个人的成绩一样，ROWNUMBER() 也会硬生生地给它俩分出个先后。那先后按什么逻辑定呢？依靠 OVER 子句里 ORDER BY 后面的列。如果 ORDER BY 后面只有分数，两个同分的人谁排前面是随机的，这在某些场景下是致命缺陷。解决办法是加一个“决胜列”，比如学号、考试用时、交卷时间：
sql复制ROW_NUMBER() OVER (PARTITION BY ClassID ORDER BY Score DESC, StudentID ASC)
这样同分的情况下，学号小的人排在前面，结果就是确定性的，可复现。
RANK() 的做法是：遇到并列就占用同一个名次，但后面会“跳号”。比如两个人并列第一，下一个人直接排第三，第二名的位置是空的。这种规则非常符合体育比赛和很多考试的习惯——“并列第一”后面自然是“第三名”，因为有一二名共占了两席。
DENSE_RANK() 则不一样，它不跳号。并列第一之后，下一个人还是第二名，整个名次序列是连续的。“DENSE”这个单词的意思就是“稠密的、紧密的”，名次之间没有空隙。
我在给客户做需求调研的时候，经常遇到业务方自己都说不清楚到底要哪种。这时候我就会把三种规则的实际效果列成一张表，让业务对着选：
| 分数 | ROW_NUMBER() | RANK() | DENSE_RANK() |
|---|---|---|---|
| 98 | 1 | 1 | 1 |
| 97 | 2 | 2 | 2 |
| 97 | 3 | 2 | 2 |
| 95 | 4 | 4 | 3 |
| 93 | 5 | 5 | 4 |
这张表我建议你收藏。实际开发中，绝大多数“榜单”场景要的是 RANK()，比如“这次考试并列第三的有多少人”；而如果要做“这个学生排在前百分之几”这类百分比计算，DENSE_RANK() 更合适，因为名次连续、分母稳定；ROWNUMBER() 则多用于“只要一个结果”的场景，比如每个班取第一名、每个科目取前三名。
2.2 PARTITION BY 和 ORDER BY 的执行顺序里藏着什么玄机？
有很多读者刚开始用 PARTITION BY 的时候会有一个疑惑：既然分组了，那 ORDER BY 到底是在整个表排序还是在分组内排序？这里面的执行顺序其实很有意思。
窗口函数的计算时机是在 WHERE、GROUP BY、HAVING 都执行完之后，ORDER BY 输出到客户端之前。它更像是一个“后置处理器”——先把满足条件的数据集确定好，再进行分区、排序、编号。
这个特性带来的一个重要推论是：窗口函数不能用在外层的 WHERE 子句里。因为 WHERE 执行的时候，窗口函数的结果还没算出来。这也是新手最容易踩的坑。后面我在常见问题章节里会专门讲这个。
另一个细节是，PARTITION BY 和 ORDER BY 虽然都出现在 OVER 子句里，但它们的职责完全不同。PARTITION BY 负责划定“鱼塘”，ORDER BY 负责决定“鱼塘里的鱼按什么顺序游”。你可以没有 PARTITION BY 直接只写 ORDER BY，此时整个结果集就是一个大分区，所有行在一起排名——这就是全年级大排名：
sql复制SELECT StudentID, Score,
RANK() OVER (ORDER BY Score DESC) AS GlobalRank
FROM ScoreTable;
但是你不能不写 ORDER BY 只写 PARTITION BY 去排名——排名是依赖“顺序”的，没有顺序就不存在“第几名”这个说法。如果你只写 PARTITION BY 不写 ORDER BY，SQL Server 不会报语法错误，但算出来的东西没有实际意义。更严格地说，某些窗口函数（比如 SUM() 这种聚合类窗口函数）可以不写 ORDER BY，但排名类的三个函数必须有 ORDER BY。
2.3 聚合函数 + 窗口函数组合：排名场景的进阶玩法
排名函数只是窗口函数的入门形态，真正实现“一次查询搞定分析报表”的，是聚合函数和窗口函数组合使用。比如我要算出每个学生的成绩、班内排名、班级平均分、班级最高分，传统写法要写好几个子查询再 JOIN 起来，用窗口函数一步就能完成：
sql复制SELECT
StudentID,
Score,
RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC) AS ClassRank,
AVG(Score) OVER (PARTITION BY ClassID) AS ClassAvg,
MAX(Score) OVER (PARTITION BY ClassID) AS ClassMax
FROM ScoreTable;
这四条信息在同一行里返回，不产生额外的连接操作，可读性和性能都远胜传统写法。AVG(Score) OVER (PARTITION BY ClassID) 这个表达式，意思就是“在班级这个分区内求平均分”，每个班级的行都会带着自己班的平均分行走，不需要再手动 JOIN 一张分组统计表。这是我做报表时最常用的写法，省掉的 JOIN 次数数都数不清。
关于聚合窗口函数，还有一个隐藏知识点：OVER 子句里的 ORDER BY 可以配合 ROWS 或 RANGE 来定义“滑动窗口”的大小，比如“算从本月到当前为止的累计平均分”。不过这是另一个话题了，本文的排名场景用不到，先按下不表。
3. 完整实战：从建表到排名结果一步步跑通
3.1 建表与造数
光讲理论没意思，我们直接拿一个真实场景来跑通全流程。假设我现在要处理一个年级的成绩排名需求，数据表设计如下：
sql复制CREATE TABLE StudentScores (
StudentID INT NOT NULL,
StudentName NVARCHAR(50) NOT NULL,
ClassID INT NOT NULL,
Subject NVARCHAR(50) NOT NULL,
Score DECIMAL(5, 2) NOT NULL,
ExamDate DATE NOT NULL
);
字段含义很直白：学生 ID、姓名、班级 ID、科目、分数、考试日期。我特意把科目也放进来，因为后面会做“单科排名”和“总分排名”两个维度，这样一张表就能覆盖两个需求。
接着插入一批测试数据。我这里用 T-SQL 的循环语句快速生成，方便演示：
sql复制DECLARE @i INT = 1;
WHILE @i <= 60
BEGIN
INSERT INTO StudentScores (StudentID, StudentName, ClassID, Subject, Score, ExamDate)
VALUES (
@i,
N'学生' + CAST(@i AS NVARCHAR(10)),
(@i - 1) / 20 + 1,
CASE WHEN @i % 3 = 1 THEN N'语文'
WHEN @i % 3 = 2 THEN N'数学'
ELSE N'英语' END,
ROUND(50 + RAND() * 50, 2),
'2025-01-15'
);
SET @i = @i + 1;
END;
这段脚本的逻辑是：把 60 个学生平均分成 3 个班，每个班 20 人，每名学生随机分配一门科目，成绩在 50 到 100 分之间随机生成。这里有个细节要注意：RAND() 在循环里的表现。如果你在一个 WHILE 循环里连续多次调用 RAND()，SQL Server 可能会返回相同的结果，因为 RAND() 是按语句级别复用的。真要造大规模测试数据，更稳妥的方案是用 CHECKSUM(NEWID()) 或者 ABS(CAST(NEWID() AS BINARY(6)) % 50) 这种方式来生成随机数。我这里为了演示方便用了 RAND()，但你实际项目中造数一定要避开这个坑。
3.2 一次查询拿到四种排名维度
数据准备好了，现在来写核心查询。假设我要一次性给业务方输出这几种排名：
- 全年级大排名（不分班）
- 班内排名
- 班内按科目的排名
- 分数段排名（这个用 NTILE 实现，后面讲）
直接用一条 SQL 出四列排名：
sql复制SELECT
StudentID,
StudentName,
ClassID,
Subject,
Score,
RANK() OVER (ORDER BY Score DESC) AS SchoolRank,
RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC) AS ClassRank,
RANK() OVER (PARTITION BY ClassID, Subject ORDER BY Score DESC) AS SubjectRankInClass,
DENSE_RANK() OVER (ORDER BY Score DESC) AS SchoolDenseRank
FROM StudentScores
ORDER BY SchoolRank;
执行完你会看到类似这样的结果：
| StudentID | StudentName | ClassID | Subject | Score | SchoolRank | ClassRank | SubjectRankInClass | SchoolDenseRank |
|---|---|---|---|---|---|---|---|---|
| 58 | 学生58 | 3 | 英语 | 98.50 | 1 | 1 | 1 | 1 |
| 41 | 学生41 | 3 | 语文 | 97.20 | 2 | 2 | 1 | 2 |
| 23 | 学生23 | 2 | 数学 | 97.20 | 2 | 1 | 1 | 2 |
| 7 | 学生7 | 1 | 英语 | 96.80 | 4 | 1 | 1 | 3 |
注意看第二行和第三行：两个学生的成绩都是 97.20，在全年级大排名中 RANK() 都给 2，跳过了 3，下一个直接排到 4。而在 DENSE_RANK() 这一列，两个 97.20 都排 2，下一个 96.80 排 3，名次是连续的。这个对比非常直观地体现了 RANK 和 DENSE_RANK 的核心差异。
班内排名的写法也很顺——只要在 PARTITION BY 里加上 ClassID，就自动按班级分组排名了。而班内单科排名则是在 PARTITION BY 里同时放 ClassID 和 Subject 两个列，实现“先按班级分、再按科目分”的两级分区。这就是 PARTITION BY 支持多列组合的威力，你可以把任意多个维度叠在一起，形成“区中区”。
3.3 用 CTE 把排名结果固化下来，方便二次使用
有经验的读者到这里可能会问：如果我想“取每个班的第一名”或者“查出每个班排名前五的人”，该怎么办？这就要用到 CTE（公用表表达式）了。窗口函数的结果列不能直接放进 WHERE 条件，但可以用 CTE 包一层之后再过滤：
sql复制WITH RankedScores AS (
SELECT
StudentID,
StudentName,
ClassID,
Score,
RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC) AS ClassRank
FROM StudentScores
)
SELECT StudentID, StudentName, ClassID, Score, ClassRank
FROM RankedScores
WHERE ClassRank = 1;
这段 CTE 的逻辑是：先算好班内排名，再到外层把排名等于 1 的行筛出来，得到的就是每个班的最高分得主。这个模式是我日常开发中使用频率最高的写法——“先排名，再筛选”几乎可以套用到所有榜单需求上。而且 CTE 天然支持多层嵌套，你可以一层层往上叠，每一层都在上一层的结果上做进一步加工，逻辑非常清晰，排查问题也方便。
3.4 给分数分档：NTILE() 的妙用
排名除了精确名次，还有一种常见的业务口径是“分档”——把全部考生按成绩分成 A、B、C、D、E 五档。这种需求用 NTILE() 函数一行就搞定：
sql复制SELECT
StudentID,
Score,
NTILE(5) OVER (ORDER BY Score DESC) AS ScoreLevel
FROM StudentScores;
NTILE(5) 的含义是：把分区内的所有行尽可能均匀地分成 5 组，第一组是分数最高的那批，第二组次之，以此类推。这个函数在业务中的典型用法是“分位数分析”——比如我要把全校学生的成绩按五分位来划分，看看前 20% 的线是多少分，NTILE 就非常合适。实际项目中，我一般会先算出 NTILE 的值，再根据档位线做后续的分数段统计。
4. 性能优化与索引使用心得
4.1 窗口函数为什么会慢？问题通常出在哪
很多人用窗口函数跑大表，一慢就骂数据库，其实窗口函数本身的设计并不慢。它的执行计划在 SQL Server 里通常表现为一个 Segment + Sort 操作——先对数据按 PARTITION BY 和 ORDER BY 的列排序，然后在分区边界处重启计算。真正的性能瓶颈就出在排序上。
如果你在 OVER 子句里写的 PARTITION BY 和 ORDER BY 列，恰恰有一组正好匹配的索引，那排序操作就有可能被省掉，因为索引本身已经按这些列排好序了。SQL Server 可以直接按索引顺序扫描，遇到分区键变化就重置窗口函数的状态——这就是“有序扫描替代显式排序”的优化思路。
4.2 索引到底该怎么建？
以我们的 StudentScores 表为例，假设高频查询是“按班级排名”，那索引应该兼顾“分区”和“排序”两个维度。分区列是 ClassID，排序列是 Score，而且排名通常是高分在前，所以索引长这样：
sql复制CREATE NONCLUSTERED INDEX IX_StudentScores_Class_Score
ON StudentScores (ClassID, Score DESC);
这个索引设计的核心思路是：索引的第一个键 ClassID 用来快速定位分区，第二个键 Score 用来保证在每个 ClassID 内部已经按分数降序排好。当窗口函数执行时，优化器发现排序顺序和索引顺序完全一致，就可以直接做流式聚合，不需要额外的 SORT 操作了。
同理，如果你经常做“单科排名”，那就建 (ClassID, Subject, Score DESC) 的组合索引；经常做“全校排名”，那就建 (Score DESC) 单列索引。索引建的准，窗口函数在大数据量下也能做到毫秒级返回。
我在一次真实项目里做过测试：一张 200 万行的成绩表，不加索引跑 RANK() 要 12 秒，加上匹配的复合索引之后降到 1 秒以内。差距就是这么夸张。
4.3 TOP N 场景的优化思路
还有一种常见场景：要取每个班的前三名。很多人的第一反应是写 ROW_NUMBER() 然后 CTE 过滤，这种方法没问题，但还有一种更高效的写法是配合 CROSS APPLY：
sql复制SELECT s.StudentID, s.StudentName, s.ClassID, s.Score
FROM (SELECT DISTINCT ClassID FROM StudentScores) AS c
CROSS APPLY (
SELECT TOP 3 StudentID, StudentName, Score
FROM StudentScores
WHERE ClassID = c.ClassID
ORDER BY Score DESC
) AS s;
这个思路是：先拿到所有班级列表，然后对每个班级单独取前三条记录。如果班级数量不多，这个查询的性能会非常好，因为它只访问每个班级头部的那几行记录，不需要像窗口函数那样扫描整个分区再排序。CROSS APPLY 本质上就是“针对外层每一行，去执行一次内层查询”，非常契合“每组分 Top N”的场景。实际项目中，我会根据数据分布选择合适的方案：班级多、每班数据量小的用窗口函数 + CTE；班级少、每班数据量大的用 CROSS APPLY。
5. 常见问题排查与避坑指南
5.1 ORDER BY 到底该用什么排序方向？
这是新手最容易犯的错误。排名通常要求“分数高的排前面”，所以 ORDER BY 要用 DESC。但如果你要算的是“用时排名”，那就是用时短的排前面，要写 ASC。方向不对，整个名次就反了。
有一个判断技巧：把排名函数想象成“按指定顺序从 1 开始编号”，顺序的第一个就是第一名。你想要谁当第一，就把它放在 ORDER BY 的第一个位置，方向按“第一的标准”来定。
5.2 RANK() 并列后跳号，业务方不认可怎么办？
这个情况我遇到太多了。业务方看到名次里出现 1、1、3，觉得是系统 bug，非要改成 1、1、2。这时候不要慌，你要先搞清楚业务方到底要什么口径：
- 如果要“并列第几”的体育比赛式名次，那是 RANK()，跳号是正常的。
- 如果要“顺序编号但有并列不占位”，那就是 DENSE_RANK()。
- 如果要“每一行都有唯一序号”，那就是 ROW_NUMBER()。
实际项目中，一般排名展示用 RANK()，导出入库用 ROW_NUMBER()（保证主键唯一），统计人数时用 DENSE_RANK()。三者各有用途，没有谁更好，只有谁更合适。
5.3 窗口函数不能用在 WHERE 里，那怎么筛选排名？
这是新手踩的最多的坑。下面这条 SQL 是错的：
sql复制-- 错误示例
SELECT StudentID, Score,
RANK() OVER (ORDER BY Score DESC) AS r
FROM StudentScores
WHERE r = 1;
报错信息会提示“列名 r 无效”。原因前面讲过：窗口函数在 WHERE 之后才执行。正确的做法是用 CTE 或者子查询包一层再过滤，代码在 3.3 节已经给过，这里不再重复。这个坑几乎人人都会踩一次，踩过之后你就记住窗口函数的执行时机了。
5.4 同样的成绩，每次执行排名结果不一样？
这种情况通常发生在 ROW_NUMBER() 或者 TOP N 场景，而且 PARTITION BY 或 ORDER BY 里存在并列值。当排序键完全相同时，SQL Server 无法保证行之间的先后顺序，结果就可能不稳定。解决办法是在 ORDER BY 里追加一个唯一的决胜列（比如 StudentID、ExamID），让排序键完全唯一：
sql复制ROW_NUMBER() OVER (PARTITION BY ClassID ORDER BY Score DESC, StudentID ASC)
增加这个列之后，排名结果就完全可复现了。这在做分页、导出、重跑报表时非常重要，否则两次跑同一份数据结果对不上，业务方会直接怀疑系统的准确性。
5.5 排查实操技巧：用 SET STATISTICS 看瓶颈
如果你发现窗口函数查询性能不理想，建议先别急着改 SQL，先看执行计划。最简单的做法是打开两项统计信息：
sql复制SET STATISTICS TIME ON;
SET STATISTICS IO ON;
然后在执行查询之后观察输出信息，重点看逻辑读次数和 CPU 耗时。如果逻辑读特别高，大概率是索引缺失或者索引没被用到；如果 CPU 高但逻辑读低，可能是排序计算太耗时，这时候就要考虑优化排序键或者重写查询。这个排查思路适用于所有窗口函数场景，不限于排名。
6. 拓展：窗口函数在真实业务里的落地经验
写到这里，我的建议是：哪怕你现在的项目暂时用不到排名，也值得把 PARTITION BY 这套思维学好。因为它本质上是一种“分组计算”思想的升级——以前分组计算只能靠 GROUP BY 把多行压成一行，现在窗口函数让每一行都能带上自己所在分组的统计信息。这个能力在报表分析、名单筛选、异常检测等领域都有非常广泛的应用。
就拿我接手的一个考试分析系统来说，最开始业务方只要求“给每个学生算个年级排名”，后来需求很快蔓延到“按班级排名”、“按科目排名”、“看学生成绩波动”、“统计每个分数段的人数”。如果没有窗口函数，这些需求每一个都得写一坨子查询，最后拼成长得吓人的 SQL，维护成本极高。用窗口函数之后，所有排名需求都是一行 OVER 子句的事，新需求来了复制粘贴改个 PARTITION BY 就完事。
我个人在实际操作中还有一个习惯：把所有窗口函数查询统一封装成视图或者表值函数。这样做的好处是，业务方只需要 select 视图就能拿到各种排名结果，不需要知道底层窗口函数怎么写的，也方便统一维护排序规则。比如我们的系统里就有一个 v_StudentRankView，里面包含了全校排名、班内排名、校内外等十几个排名列，任何新报表要数据，直接从这个视图取，不用再写复杂 SQL。这个方案的唯一注意事项是：视图里如果存在多层窗口函数嵌套，性能要提前压测，该建索引的建索引，该加筛选条件的加筛选条件。
关于 PARTITION BY 排名实战的内容，这里基本把核心的东西都讲透了。从三兄弟函数的差异、到完整的建表查询流程、再到性能优化和避坑，每个环节我都踩过坑、填过坑。如果你正在做成绩排名相关的功能，按这个流程走一遍，基本能少走一个星期的弯路。最后再提醒一句：写完排名 SQL 别忘了在真实数据量下压测一次，索引建没建好、排序键对不对，一跑全知道。