窗口函数不能替代group by做增量聚合，但能实现group by无法完成的保留明细行的累计计算、动态窗口聚合及可控去重等etl关键操作。
窗口函数能替代GROUP BY做增量聚合吗？
不能直接替代，但能解决GROUP BY做不到的事。比如在ETL中计算「截至当前行的累计销售额」或「每个用户最近3次订单的平均金额」，GROUP BY会压缩行数、丢失明细，而窗口函数保留原始粒度，同时产出聚合结果。
常见错误现象：SELECT user_id, SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) 写成 GROUP BY user_id 后再加 SUM()，导致无法关联到单条订单的其他字段（如商品ID、渠道来源）。
- 必须用
OVER子句明确定义窗口范围：PARTITION BY控制分组边界，ORDER BY控制排序和帧（frame）逻辑 - 需要累计值时，记得显式写
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则不同数据库默认行为不一致（PostgreSQL 默认是这个，MySQL 8.0+ 默认是RANGE，可能引发重复计数） - 在ETL中间层用窗口函数生成指标列（如
row_number() OVER (PARTITION BY sku_id ORDER BY updated_at DESC)），比在应用层用Python排序+去重更稳定、可审计
在ETL清洗阶段用ROW_NUMBER()去重为什么比DISTINCT更可控？
因为 DISTINCT 是对整行去重，而真实业务中「重复」往往有业务定义：比如同一订单号出现两次，要保留更新时间更晚的那条；或同一手机号注册多个账号，要按注册顺序取第一个。这时 ROW_NUMBER() 配合 PARTITION BY + ORDER BY 才真正表达业务意图。
使用场景：源系统同步过来的订单表含脏数据，order_id 不唯一，但业务规则是「同order_id取updated_at最大的一条」。
- 写法示例：
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC, id DESC)—— 后面加id DESC是防时间相同时序不确定 - 别漏掉
WHERE rn = 1这一步，窗口函数本身不筛选，只是打标 - 注意：如果源表没有可靠的时间戳或主键，
ORDER BY缺失会导致ROW_NUMBER()结果不可复现，ETL任务就不可靠
为什么在ETL中慎用LEAD/LAG做状态变化检测？
因为 LEAD() 和 LAG() 依赖严格有序的分区数据，而ETL上游常存在时间精度丢失、乱序写入、空值干扰等问题，直接用容易漏判或误判状态切换点。
典型错误现象：用 LAG(status) OVER (PARTITION BY user_id ORDER BY event_time) 判断用户“从active变inactive”，结果发现某次状态回滚没被捕捉——原因是两条事件时间相同，数据库内部排序不稳定，LAG 拿到的不是上一条真实状态。
- 必须确保
ORDER BY字段组合能唯一确定行序，推荐追加一个可排序的唯一字段（如event_id或log_id） - 对空值敏感：如果
event_time为NULL，整行可能被排到最后，LAG就会跨用户取值，加WHERE event_time IS NOT NULL预过滤 - 性能提示：在大宽表上对高基数字段（如
user_id）开窗口，LAG可能触发大量随机IO，不如先用GROUP BY + ARRAY_AGG（PostgreSQL）或物化中间状态
窗口函数在ETL调度中容易被忽略的执行代价
窗口函数不是“免费”的——它强制数据库做全分区扫描和内存排序，尤其当 PARTITION BY 基数低（如全表只分1个区）、ORDER BY 字段无索引时，很容易把ETL任务拖成慢查询。
例如：每天跑一次的销售汇总任务，用 AVG(sales) OVER (PARTITION BY region ORDER BY date)，但region只有5个值，相当于每次对全量销售数据排序，而实际只需要每个region的滚动均值。
- 检查执行计划里有没有
WindowAgg节点配合Sort，如果有且耗时占比高，优先考虑加复合索引：(region, date) - MySQL 8.0+ 中，带
ORDER BY的窗口函数若无法走索引，会强制建临时表，看EXPLAIN FORMAT=TREE是否出现MATERIALIZE - 在Airflow或dbt中调用含窗口函数的SQL前，务必用
EXPLAIN ANALYZE实测，别只信开发环境的小数据集
ROW_NUMBER()写错ORDER BY，可能让每天凌晨跑的任务多花40分钟——而这40分钟，通常不会报错，只会默默拖垮整个链路的SLA。
