RANK()函数实现同分并列且跳名次的发奖逻辑：相同分数者获得相同名次，后续名次跳过；需在ORDER BY中明确排序依据，多字段排序须写全；取前N名须用RANK()≤N过滤，不可用TOP N。
用 RANK() 实现同分并列、跳名次的发奖逻辑
当多人分数相同时，需要并列名次（比如两个第1名），且后续名次跳过（第3名之后是第4名，不是第2名），RANK() 是最直接的选择。它按分区排序后，对相同值分配相同序号，并自动跳过被占用的后续序号。
常见错误是误用 ROW_NUMBER()——它强行给每行唯一编号，完全不处理并列；或用 DENSE_RANK() 却没意识到它不跳名次（两个第1名后直接是第2名），不符合“发奖名额固定”的业务场景（例如只颁前三名奖，但允许并列第1）。
-
RANK()的排序依据必须明确写在ORDER BY子句中，且不能是常量或无序表达式，否则结果不可靠 - 若需按多个字段排序（如先按分数降序，分数相同时按提交时间升序），要写成
ORDER BY score DESC, submit_time ASC - 发奖时通常还需限制总人数，比如“取 RANK ≤ 3 的所有记录”，不能写成
TOP 3，否则会截断并列者
SELECT name, score,
RANK() OVER (ORDER BY score DESC) AS award_rank
FROM contest_scores
WHERE RANK() OVER (ORDER BY score DESC) <= 3;为什么不能直接在 WHERE 中用窗口函数？
SQL Server 不允许在 WHERE 子句中直接调用窗口函数，会报错 "Windowed functions can only appear in the SELECT or ORDER BY clauses"。这是语法硬限制，不是版本问题。
正确做法是用 CTE 或子查询包裹窗口计算，再在外层筛选。CTE 更清晰，也避免重复写 OVER 子句。
- 别写：
WHERE RANK() OVER (...) —— 必报错 - 要写：先在 CTE 里算出
award_rank，再SELECT * FROM cte WHERE award_rank - 如果数据量大，注意
ORDER BY字段是否已建索引；score DESC上的非聚集索引能显著加速RANK()计算
WITH ranked AS (
SELECT name, score,
RANK() OVER (ORDER BY score DESC) AS award_rank
FROM contest_scores
)
SELECT name, score, award_rank
FROM ranked
WHERE award_rank <= 3;
RANK() 和 DENSE_RANK() 在发奖场景的关键区别
区别不在“是否并列”，而在于“后续名次是否跳过”。两者对相同分数都给相同排名，但处理空档的方式不同：前者跳过（1,1,3,4），后者紧排（1,1,2,3）。发奖名额有限时，这个差异直接决定谁得奖。
举例：分数为 [100,100,95,90]，取前3名奖：
-
RANK()→ 排名 [1,1,3,4]，award_rank 返回前三行（含两个100分 + 一个95分），共3人获奖 -
DENSE_RANK()→ 排名 [1,1,2,3]，同样条件会返回全部4人，因为第四人award_rank = 3 - 业务上若要求“最多3个获奖名额”，必须用
RANK()；若要求“前三名次的所有获得者”，才考虑DENSE_RANK()
分区发奖时记得加 PARTITION BY
如果比赛分组（如按部门、年龄段），需要组内独立排名，必须显式写 PARTITION BY dept_id。漏掉会导致全表统一排序，跨组干扰名次。
常见疏忽是把 PARTITION BY 和 GROUP BY 混淆——窗口函数不需要也不能和 GROUP BY 混用（除非聚合后再开窗），且 PARTITION BY 不会减少行数。
- 正确：
RANK() OVER (PARTITION BY dept_id ORDER BY score DESC) - 错误：在含
GROUP BY dept_id的查询里直接写RANK() OVER (ORDER BY score)，会报错或结果异常 - 如果某组人数极少（如只有1人），
RANK()仍返回 1，不会补位；这点和人工评奖习惯一致
实际部署时最容易忽略的是：业务方说的“前三名”到底是“名次≤3”还是“取前3条记录”。前者必须用 RANK() + CTE 筛选，后者用 TOP 3 就够——但后者在并列时必然丢人。确认清楚这句话的语义，比写对 SQL 更关键。
