直接给出结论：在 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() 实现“每个班级成绩前三名”，正确的写法是：DENSE_RANK() OVER (PARTITION BY ClassID ORDER BY Score DESC)。这里 PARTITION BY 必须位于 ORDER BY 之前，这是语法规定——先指定分组，再指定排序。如果顺序颠倒，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()会将 NULL 排在开头或末尾（取决于 SQL Server 的排序规则），这可能打乱预期顺序。
说到这，有一个实际经验必须提醒：真正让你在复杂报告中卡住的，往往不是函数本身，而是窗口函数返回的是中间计算列——你不能在 WHERE 中直接引用 RANK() 的别名，必须通过子查询或 CTE 包裹一层；另外，当 ORDER BY 中包含多个字段且排序方向不一致时（例如 ORDER BY Dept ASC, Salary DESC），OVER 子句中的排序也需要严格同步，否则排名逻辑与最终的显示顺序会错位，导致报告混乱。
