SQL如何实现销售目标的达成率排名：窗口函数综合应用
想用 ROW_NUMBER() 或 RANK() 直接给销售达成率排名？这里有个常见的坑：如果不对达成率这个计算字段做预处理，结果很可能南辕北辙。问题往往出在数据本身——那些NULL值、零目标或者负值，如果不加处理就直接扔进排序，业务逻辑就全乱了。
达成率字段必须先处理再参与窗口排序
达成率计算，表面看就是 实际销售额 / 销售目标。但真实数据哪有这么干净？目标值为零、实际销售额为NULL，甚至目标字段压根没填的情况比比皆是。如果图省事，直接写 RANK() OVER (ORDER BY actual/target DESC)，数据库要么报错，要么给出匪夷所思的结果——比如把NULL值排在最前面，这显然不符合“排除无效数据”的业务常识。
那该怎么办？关键在于分步走：
- 第一步，务必在查询中先用
CASE表达式“清洗”出干净的达成率。比如下面这个写法，就只对目标大于零的有效记录进行计算，并保留四位小数：CASE WHEN target > 0 THEN ROUND(actual::DECIMAL / target, 4) ELSE NULL END AS achievement_rate
- 第二步，在窗口函数的
ORDER BY子句中，引用这个计算好的achievement_rate别名，而不是现场做除法。 - 最后，别忘了加上
WHERE achievement_rate IS NOT NULL这个过滤条件。这能确保参与排名的都是有效数据，避免无效记录打断排名的连续性。
分组内排名必须用 PARTITION BY department_id
“按部门看看谁完成得最好”——这句话的重点是“按部门”。这意味着排名不是全公司大乱斗，而是每个部门内部独立进行的较量。如果漏写了 PARTITION BY，结果就是把销售总监和新人放在同一个榜单上比较，这种排名毫无意义。
- 错误示范：
RANK() OVER (ORDER BY achievement_rate DESC)→ 这得到的是全公司一张榜。 - 正确姿势：
RANK() OVER (PARTITION BY department_id ORDER BY achievement_rate DESC)→ 这才是每个部门内部独立排名。 - 还有一点值得注意：如果部门ID字段存在空值（
department_id IS NULL），这些行在窗口函数中会被归到同一个隐含的分组里。为了避免混淆，建议提前用WHERE department_id IS NOT NULL过滤掉。 - 语法兼容性上，MySQL 8.0+ 和 PostgreSQL 都支持这种写法。如果是旧版MySQL（
选 RANK() 还是 DENSE_RANK()？看业务是否允许“并列跳名次”
假设部门里有两个销售，达成率都是120%，紧随其后的第三人是115%。这时，第三名应该叫“第3名”还是“第2名”？这个选择决定了你用哪个函数。
- 用
RANK()：排名结果是1, 1, 3。它允许名次跳跃，适合那些强调“差距感”的管理场景，比如绩效强制分布。 - 用
DENSE_RANK()：排名结果是1, 1, 2。名次是连续的，适合需要后续按固定名次筛选的场景。例如“取每个部门前三名”，如果用RANK()，遇到并列情况实际返回的行数可能超过3。 - 至于
ROW_NUMBER()，这里基本用不上。它会强行给相同达成率的人分配不同的序号（如1, 2, 3），这违背了“达成率一致则表现一致”的基本业务逻辑。
真实查询要带过滤条件，不能只靠窗口函数兜底
窗口函数只管排序和编号，它可不会帮你考虑数据时效、有效性或者权限范围。一个能直接上生产环境的达成率排名查询，至少还得处理好下面几件事：
- 时间范围：加上
WHERE sale_month BETWEEN '2026-01' AND '2026-03'这样的条件。否则，历史数据或未来数据都会混进来干扰当前的排名。 - 状态过滤：记得排除那些已取消的订单（
status = 'canceled'）或者已被标记删除的目标记录（is_deleted = true）。 - 权限隔离：如果系统涉及多组织架构，查询里必须通过
AND org_id = ?这样的参数进行数据隔离，不能依赖应用层再做二次过滤。 - 性能提醒：当数据量达到百万级时，
PARTITION BY加上ORDER BY的操作可能会变慢。在department_id和sale_month这类常用过滤和分组字段上建立联合索引，是个好习惯。
说到底，真正的难点不在于写出 RANK() OVER 这句语法，而在于想清楚：哪些人应该参与排名？按照什么业务规则来排？排名结果最终怎么使用？当这些业务规则嵌套进计算字段和层层过滤条件之后，窗口函数，其实只是完美执行链条上的最后一环罢了。
