窗口函数与group by的根本区别在于输出行数：group by压缩行数、丢失明细，输出行数≤输入；窗口函数保留原表所有行，每行附加计算值，输出行数=输入行数。
因为窗口函数能直接解决「既要分组统计，又要保留原始行」这个最常见又最棘手的分析矛盾——不用自连接、不丢明细、一行SQL就能出结果。
窗口函数和GROUP BY的根本区别在哪？
关键就看输出行数是否变化：GROUP BY会把多行压成一行，原始数据细节全丢；而窗口函数用OVER()开窗后，输入多少行，输出还是多少行，每行都带一个计算值。
比如查“每个员工薪资比部门平均高多少”，用GROUP BY得先聚合出部门均值再关联原表；用窗口函数直接写：salary - AVG(salary) OVER (PARTITION BY department)，干净利落。
- 误用场景：把
RANK() OVER (...)放在GROUP BY查询里，会报错或逻辑错——窗口函数不能和聚合混在同一层级 - 性能提示：
PARTITION BY列和ORDER BY列最好有联合索引，否则大数据量下排序开销陡增
哪些函数必须会？优先级怎么排？
不是所有窗口函数都同等重要。日常高频且不可替代的是这三类：
-
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算时间窗口，遇到重复日期会意外扩大窗口范围 - 兼容性注意：MySQL 8.0+、PostgreSQL、Snowflake、Hive 3.0+ 都支持完整语法，但旧版Hive只认
ROWS，不支持RANGE时间类型
真正难的不是记住函数名，而是每次写OVER()前，想清楚三件事：按什么分组、按什么排序、窗口边界到底划到哪——边界画错，结果就全偏了。
