窗口函数更适合“分组统计且保留明细”，因其不改变行数、避免 JOIN、支持向量化；需注意 PARTITION BY 逻辑分组、ORDER BY 定义窗口内顺序而非最终排序，ROWS BETWEEN 比 RANGE BETWEEN 更高效稳定，且窗口函数不可用于 WHERE 或 JOIN 条件。
窗口函数比 GROUP BY 更适合“既要分组统计又要保留明细”
遇到需要按用户、时间、地区等维度聚合，但又不能丢掉原始行（比如算每个订单的金额占该用户总金额比例），GROUP BY 就得套子查询或 JOIN 回原表，IO 和执行计划都变重。窗口函数直接在原行上补计算结果，不改变行数，执行引擎也更容易做向量化优化。
常见错误现象：ERROR: column "xxx" must appear in the GROUP BY clause —— 其实不是真要分组，只是想按某列“分区”算累计值或排名。
- 用
OVER (PARTITION BY user_id ORDER BY order_time)替代GROUP BY user_id+ 关联 -
PARTITION BY是逻辑分组，ORDER BY决定窗口内排序（影响ROW_NUMBER()、SUM() OVER (ROWS BETWEEN ……)等行为） - 没写
ORDER BY时，COUNT() OVER (PARTITION BY x)能用，但LAG()或累计求和会报错或结果不可控
ORDER BY 在窗口定义里不是“排序最终结果”，而是定义窗口顺序
很多人以为加了 ORDER BY 就等于最后输出有序，其实它只影响窗口函数内部的计算逻辑。最终结果顺序还得靠外层 ORDER BY。不注意这点，LEAD() 取错下一行、ROW_NUMBER() 排序乱、累计求和断点都是常事。
使用场景：查每个用户的首单时间、最近三笔订单平均金额、同比环比。
-
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time)→ 首单是rn = 1，不是靠外层ORDER BY -
AVG(amount) OVER (PARTITION BY user_id ORDER BY create_time ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)→ 必须有ORDER BY才能定义“前两行” - 如果分区字段本身有重复值（比如多个订单同秒创建），
ORDER BY create_time不够稳定，建议补个唯一字段如ORDER BY create_time, order_id
ROWS BETWEEN 和 RANGE BETWEEN 的性能与语义差异很大
ROWS BETWEEN 按物理行偏移，快且确定；RANGE BETWEEN 按排序值范围匹配，易出意外——尤其当排序字段有大量重复值时，可能把几百行全卷进一个窗口，拖慢查询甚至 OOM。
错误现象：SUM(x) OVER (ORDER BY dt RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW) 在日期稀疏时返回极大窗口，而预期只是最近 7 天的记录。
- 时间类滑动窗口优先用
ROWS BETWEEN+ 子查询预处理成连续序列，或用GENERATE_SERIES补齐 -
RANGE仅适合数值型且分布密集的场景（比如精确到毫秒的时间戳、自增 ID） - PostgreSQL 14+ 对
RANGE做了优化，但 Hive/Trino/Spark SQL 仍普遍慢于ROWS
窗口函数不能出现在 WHERE 或 JOIN ON 条件里
这是语法硬限制：窗口函数属于 SELECT 阶段计算，而 WHERE 和 JOIN ON 发生在更早阶段。想筛“用户累计消费超 1000 的订单”，不能写 WHERE SUM(amount) OVER (……) > 1000，得用子查询或 CTE。
典型卡点：指标下钻时想动态过滤，结果报错 window functions are not allowed here。
- 正确做法：用 CTE 包一层，
SELECT * FROM (SELECT *, SUM(……) OVER (……) AS total FROM t) s WHERE total > 1000 - 别在
ON里写LEFT JOIN b ON a.id = b.id AND ROW_NUMBER() OVER (……) = 1—— 改用FIRST_VALUE()配合去重逻辑 - 某些引擎（如 Spark SQL）支持在
HAVING里用窗口函数，但标准 SQL 不保证，别依赖
真正麻烦的是嵌套窗口：先按天累计，再对累计值做移动平均。这种得至少两层 CTE，每层都可能放大 shuffle 数据量——别光看语法通不通，得盯住执行计划里的 WindowOperator 节点数和数据倾斜情况。
