窗口函数和GROUP BY，到底有啥区别？不少人刚开始接触时，总觉得它们都能做分组计算，甚至试图互相替代。但事实上，两者作用层级完全不同——GROUP BY做的事情是聚合归并，把多行压成一行，输出行数≤输入行数，原始细节全部丢失；而窗口函数用OVER()开窗之后，输入多少行，输出还是多少行，每一行都能附带上一个计算出来的统计值。说白了：要压缩行数，用GROUP BY；要在每行旁边都挂个汇总数，用OVER。
窗口函数之所以成为数据分析师的必备技能，核心原因就是它直击一个最常见又最棘手的矛盾：既要分组统计，又舍不得丢掉原始行的明细数据。不用写自连接、不丢明细、一行SQL就能出结果——这才是真正的效率提升。
窗口函数和GROUP BY输出行数差异决定用法边界
GROUP BY会把多行压缩成一行，原始数据细节全丢；窗口函数用OVER()开窗后，输入多少行，输出还是多少行，每行都带一个计算值。
一个典型的错误场景：想查“每个员工薪资比部门平均高多少”，不少人第一反应是用GROUP BY department先算平均值，再通过子查询关联回来。结果就是多写三张子查询、性能差、逻辑还容易出错。
- 正确写法：
salary - A VG(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 ()和A VG() OVER ()：累计求和、移动平均，财务和运营报表里几乎天天见。
RANK()和DENSE_RANK()虽然也常用，但多数情况下ROW_NUMBER()更可控——毕竟并列排名在业务口径里经常需要人工干预，直接用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()之前，想清楚三件事：按什么分组、按什么排序、窗口边界到底划到哪——边界画错，结果就全偏了。
