为何SQL窗口函数是数据分析师必备的进阶技能？

窗口函数不能替代GROUP BY，因二者作用层级不同：GROUP BY聚合归并行集（输出行数≤输入），OVER保留原始行结构叠加计算（输出行数=输入）；需压缩行数用GROUP BY，需每行附加统计值才用OVER。

因为窗口函数能直接解决「既要分组统计，又要保留原始行」这个最常见又最棘手的分析矛盾——不用自连接、不丢明细、一行SQL就能出结果。

窗口函数和GROUP BY输出行数差异决定用法边界

GROUP BY会把多行压成一行，原始数据细节全丢；窗口函数用OVER()开窗后，输入多少行，输出还是多少行，每行都带一个计算值。

常见错误现象：想查“每个员工薪资比部门平均高多少”，却用GROUP BY department先算均值再关联，结果多写三张子查询、性能差、逻辑易错。

• 正确写法：salary - AVG(salary) OVER (PARTITION BY department)
• 误用场景：把RANK() OVER ()放在GROUP BY查询里，会报错或逻辑错——窗口函数不能和聚合混在同一层级
• 兼容性注意：MySQL 8.0+、PostgreSQL、Snowflake、Hive 3.0+ 都支持完整语法，但旧版Hive只认ROWS，不支持RANGE时间类型

必须优先掌握的三类高频窗口函数

不是所有窗口函数都同等重要。日常高频且不可替代的是这三类：

• ROW_NUMBER()：严格序号，做Top N、分页、去重（配合PARTITION BY取每组第一条）
• LAG()和LEAD()：跨行取值，算环比、同比、用户行为路径（如上一次下单时间：LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_time)）
• SUM() OVER ()和AVG() OVER ()：累计求和、移动平均，财务/运营报表里几乎天天见

RANK()和DENSE_RANK()虽然常用，但多数时候ROW_NUMBER()更可控——毕竟并列排名在业务口径里常要人工干预。

OVER()里的ROWS BETWEEN边界容易被忽略

默认情况下，像SUM(sales) OVER (PARTITION BY product ORDER BY month)会从分区第一行累加到当前行（等价于ROWS UNBOUNDED PRECEDING）。但如果你只想算“最近3个月滚动和”，就必须显式写：ROWS BETWEEN 2 PRECEDING AND CURRENT ROW。

漏掉这个，结果就是累计值而非滚动值，报表上线后才发现偏差，排查成本远高于写的时候多敲几个字。

• 常见错误：用RANGE代替ROWS算时间窗口，遇到重复日期会意外扩大窗口范围
• 性能提示：PARTITION BY列和ORDER BY列最好有联合索引，否则大数据量下排序开销陡增

真正难的不是记住函数名，而是每次写OVER()前，想清楚三件事：按什么分组、按什么排序、窗口边界到底划到哪——边界画错，结果就全偏了。