窗口函数用于生成统计特征而非直接打标签，如“近7日活跃天数”；GROUP BY会压缩行数、丢失时间序列细节，无法支持“最近N次”等时序敏感聚合，而窗口函数保留明细行并支持排序筛选。
直接回答核心问题：窗口函数不是用来“打标签”的，而是用来生成可作为标签依据的统计特征——比如“近7日活跃天数”“近30日下单频次排名”“首单到复购的间隔中位数”。这些特征一旦算出，就能直接映射为分类型或统计型标签（如A211U005_003），但窗口函数本身不负责打标逻辑。
为什么不能用GROUP BY做用户行为聚合统计？
GROUP BY会压缩行数，丢失用户行为的时间序列细节。例如想统计“每个用户最近3次购买金额的平均值”，如果先GROUP BY user_id再AVG(amount)，你就拿不到“第1次、第2次、第3次”各自的金额，也无法判断哪三次是“最近”的。
窗口函数保留原始行为明细行，配合ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)就能标记每笔订单的倒序序号，再用条件过滤+聚合，精准提取“最近N次”。
- 错误做法：
SELECT user_id, AVG(amount) FROM orders GROUP BY user_id→ 只有均值，无时间维度控制 - 正确路径：先加序号列 → 筛出
rn → 再对筛选后结果<code>GROUP BY user_id求均值 - 注意：窗口函数必须写在
SELECT子句中，不能出现在WHERE或HAVING里（因为执行顺序晚于它们）
如何用窗口函数计算滚动类标签特征（如7日留存率）？
留存率本质是“某日新增用户中，后续某天仍活跃的比例”，它依赖跨行时间关联，必须用LEAD()或LAG()获取相邻行为时间点。
典型步骤是：按user_id和event_date排序 → 用LEAD(event_date, 1) OVER (PARTITION BY user_id ORDER BY event_date)得到下次活跃日期 → 判断是否≤当前日+7 → 转为布尔标识 → 最后按注册日聚合统计。
-
LEAD()和LAG()默认只看相邻行，若需“7日内任意一天活跃”，得配合MIN()窗口函数 +ROWS BETWEEN CURRENT ROW AND 6 FOLLOWING帧定义 - MySQL 8.0+、PostgreSQL、Oracle 支持完整帧语法；旧版MySQL或Spark SQL需用自连接模拟，性能差且易出错
- 注意
event_date必须去重或取最小值，否则同一用户单日多行为会导致重复计数
聚合函数嵌套窗口函数时，ORDER BY和PARTITION BY怎么选？
关键看业务语义：要对比组内水平，就PARTITION BY分组；要体现趋势或累计，就必须ORDER BY；两者常共存，但顺序不能颠倒。
例如计算“用户累计消费额”：SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) —— 每个用户独立累计，且按时间升序；若去掉ORDER BY，就变成该用户所有订单的总金额，每行都一样，失去“过程感”。
- 漏写
ORDER BY：累计类（SUM/AVG）、排名类（RANK）结果不可控，数据库可能按物理存储顺序算 - 误写
ORDER BY方向：如留存分析中用DESC排event_date，LEAD()就变成往前翻，逻辑全反 -
PARTITION BY粒度要与标签维度一致：用户画像用userid，设备画像才用cookieid，混用会导致标签错挂
最易被忽略的是窗口帧（frame clause）的默认行为：没有显式声明ROWS或RANGE时，SUM() OVER (PARTITION BY x ORDER BY y)默认等价于ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，也就是“从分区开头累加到当前行”。这个隐式规则在计算移动平均或滑动窗口指标时极易引发偏差，务必确认是否符合业务定义。
