SQL中的窗口函数使用场景.docxVIP

SQL中的窗口函数使用场景

一、窗口函数的基础认知：从聚合到窗口的进化

（一）传统聚合函数的局限：为什么需要窗口函数

在SQL的世界里，聚合函数（如SUM、AVG、COUNT）曾是数据分析的核心工具——它们能将一组数据“压缩”成单个值，比如计算一个部门的平均工资、一个商品类目的总销量。但这种“压缩”有个致命缺点：会丢失原始数据的细节。比如，当我们用GROUPBY计算部门平均工资时，结果只保留“部门+平均工资”两行，无法看到每个员工的工资与部门平均的差异；若要对比，必须再用JOIN将原始数据与聚合结果关联，步骤繁琐且效率低下。

窗口函数的出现打破了这个限制。它的核心特点是“保留原始行结构”：在计算聚合值的同时，不会合并行，而是将聚合结果“附加”到每一行数据中。比如，要查看每个员工的工资与部门平均工资的对比，只需用窗口函数AVG(salary)OVER(PARTITIONBYdepartment)，就能直接在员工行后添加“部门平均工资”字段——无需额外关联，一步完成。这种“不压缩、只关联”的能力，让窗口函数成为处理复杂业务分析的“瑞士军刀”。

（二）窗口函数的核心逻辑：PartitionBy与OrderBy的组合

要理解窗口函数，必须先明确OVER子句的作用——它定义了一个“窗口”（即要分析的数据集范围）。OVER子句中最关键的两个参数是PartitionBy和OrderBy：

PartitionBy：将数据按指定字段分组，每个分组是一个独立的“窗口”。比如PartitionBydepartment会把员工按部门分成多个窗口，每个窗口内的计算独立于其他窗口。

OrderBy：定义窗口内数据的排序规则，决定计算的“方向”。比如OrderByhire_date会按入职时间对窗口内的员工排序，这对需要“按顺序计算”的场景（如累积求和、排名）至关重要。

举个简单例子：ROW_NUMBER()OVER(PartitionBydepartmentOrderBysalaryDESC)——它的含义是：按部门分组，每个部门内按工资降序排序，给每个员工分配一个唯一的行号。这个行号既是员工在部门内的工资排名，又保留了员工的所有原始信息（如姓名、入职时间）。

二、排序与排名：解决业务中的顺序问题

排序与排名是业务中最频繁的需求之一——从电商商品的销量排名，到考试成绩的名次划分，再到员工的绩效排序，几乎所有业务都需要明确“数据的相对位置”。窗口函数的ROW_NUMBER、RANK、DENSE_RANK等工具，能灵活应对不同的排名场景。

（一）ROW_NUMBER：唯一排名的场景

ROW_NUMBER的特点是为每一行分配唯一的连续整数，即使两行数据完全相同，也会按OrderBy的次关键字（如ID、时间）区分顺序。这种“唯一排名”适合需要明确数据先后顺序的场景。

比如电商行业的“商品销量排名”：某电商平台要为每个商品类目生成“热销Top10”列表，要求即使两个商品销量相同，也需按“上架时间”排序（newer商品优先）。用ROW_NUMBER的话，只需按“商品类目”分组，按“销量降序+上架时间降序”排序，就能得到每个类目的唯一排名——排名第1的商品是该类目销量最高且最新上架的，符合“热销且新鲜”的推荐逻辑。

（二）RANK与DENSE_RANK：处理并列情况的灵活选择

ROW_NUMBER的“唯一性”在某些场景下会显得生硬——比如考试成绩排名，若两个学生都考了100分，显然应该并列第1名，而非一个第1、一个第2。这时候RANK和DENSE_RANK就派上了用场：

RANK：会为并列数据分配相同的排名，但后续排名会“跳跃”。比如两个100分都是第1名，下一个分数（99分）会是第3名。

DENSE_RANK：同样为并列数据分配相同排名，但后续排名“连续”。比如两个100分都是第1名，下一个分数（99分）会是第2名。

举个教育行业的例子：某学校要统计班级考试成绩的名次，用于评优。若用RANK，能体现“并列但有差距”（比如两个第1名之后是第3名）；若用DENSE_RANK，则更强调“连续的层次”（比如两个第1名之后是第2名）。具体选择取决于业务对“排名密度”的要求——如果评优名额是“前5名”，用DENSE_RANK会更公平（因为并列第1的两个学生不会占用额外名额）。

（三）多维度排序：复杂业务的顺序定义

现实业务中，排序往往不是“单维度”的——比如企业要按“部门+入职时间”排序，查看每个部门内员工的入职先后；或按“地区+客户类型+消费金额”排序，分析不同地区的客户消费能力。窗口函数的PartitionBy支持多字段分组，OrderBy也支持多字段排序，能轻松应对这种复杂场景。

比如某企业的“员工工龄排序”需求：按“部