如何使用SQL Server窗口函数生成复杂排名报告

直接说结论：在SQL Server中进行排名统计，若需要生成一份复杂的排名报告，问题通常不在于函数选择是否正确。SQL Server 2005及以上版本均支持RANK()、DENSE_RANK()和ROW_NUMBER()这三个核心窗口函数，但很多开发者在实际应用中容易踩坑——绝大多数错误源于OVER子句中PARTITION BY与ORDER BY的排列顺序，或者后续的过滤逻辑未能准确对接业务含义。

为什么 RANK() 返回 1,1,3 而不是 1,1,2？

RANK()的并列处理机制非常直观：相同数值获得相同名次，但下一个名次会直接跳过缺失的编号。例如，两个95分同为第1名，下一个90分直接成为第3名，中间不会出现第2名。这就是跳号现象。

• 适用场景：竞赛类排名（例如两名金牌并列，银牌从第三名开始）
• 常见错误：许多用户误以为它会产生连续编号，当用于“取前N名”时，并列的条目会被遗漏
• 示例：RANK() OVER (ORDER BY Score DESC)作用于数据[95,95,90,85]时，返回结果为[1,1,3,4]

DENSE_RANK() 分组排名时需注意顺序

如果你希望使用DENSE_RANK()实现“每个班级成绩前3名”，正确写法为DENSE_RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC)。这里PARTITION BY必须位于ORDER BY之前，这是SQL Server的语法规定：先指定分组，再指定排序。若顺序颠倒，SQL Server会直接报语法错误。更常见的失误是遗漏PARTITION BY，导致结果变成全表排名，而非按班级分组排名。

• 正确写法：DENSE_RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC)
• 语法高危写法：DENSE_RANK() OVER (ORDER BY Score DESC PARTITION BY ClassID)（该顺序非法）
• 性能注意：如果PARTITION BY列上没有索引，大表的分区排序消耗会明显增加，需要特别留意

用 ROW_NUMBER() 生成严格序号，但勿用于并列场景

ROW_NUMBER()的逻辑非常简单——它不考虑数值是否重复，仅按ORDER BY的结果为每一行硬性分配1,2,3…。典型用途是“抽取第N条记录”或实现分页时确保行不丢失。但它不适合反映真实排名，例如将并列第5的两名人员强行分为第5和第6，这在业务上是不合理的。

• 典型误用：使用ROW_NUMBER()统计“销售Top 10”，结果并列第5的两人被分成第5和第6，而实际上他们都应属于Top5
• 安全用法：ROW_NUMBER() OVER (PARTITION BY Region ORDER BY Sales DESC) + WHERE rn <= 3 来提取各区域前3名。注意，这种写法会硬性截取3条记录，即使有并列也仅取3条——具体需根据业务需求判断
• 隐患点：当ORDER BY列包含NULL时，ROW_NUMBER()会按照SQL Server默认排序规则将NULL排在最前或最后，可能打乱预期顺序

说到这里，有一个实际经验必须提醒：真正让复杂报告陷入僵局的原因，往往不是窗口函数本身，而是窗口函数返回的是中间计算列——你不能在WHERE中直接引用RANK()的别名，必须通过子查询或CTE包裹一层；另外，当ORDER BY包含多个字段且排序方向不一致时（例如ORDER BY Dept ASC, Salary DESC），OVER子句中的排序也得严格同步，否则排名逻辑与最终显示顺序就会错位，导致报告混乱。