OVER()子句是OLAP分析落地的关键，通过PARTITION BY切片、ORDER BY排序及ROWS/RANGE帧定义，在保留明细前提下实现动态上下文计算；其绑定于SELECT阶段，不参与WHERE/GROUP BY等前置逻辑。
OVER() 子句不是装饰，它是 OLAP 分析能落地的关键控制点。
窗口函数被 SQL 标准列为 OLAP 分析核心工具，根本原因不是它“功能多”，而是它在不丢失明细、不依赖自连接、不破坏原始行结构的前提下，实现了传统 SQL 难以表达的“动态上下文计算”。
PARTITION BY + ORDER BY 是 OLAP 场景的最小必要抽象
OLAP 分析天然需要“按维度切片 + 按时间/指标排序 + 在局部范围内计算”。这三步在OVER() 中被固化为语法级支持：
- PARTITION BY 对应“切片”（如按 product_category 分组）
- ORDER BY 对应“排序轴”（如按 sale_date 升序）
- 二者组合后，才让 ROW_NUMBER()、LAG()、SUM() OVER(... ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 这类操作有明确语义
没有这个结构，你只能靠子查询或自连接模拟，性能差、可读性崩、且容易漏掉边界情况（比如空值排序、重复排序键）。
ROWS 和 RANGE 的差异直接影响分析结果可信度
很多实际问题卡在这一步： -ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING 是严格取物理相邻三行，适合移动平均
- RANGE BETWEEN INTERVAL '7 DAYS' PRECEDING AND CURRENT ROW（PostgreSQL/MySQL 8.0+）是按值范围滑动，但要求 ORDER BY 列必须是数值或日期类型，且对重复值行为敏感（RANGE 会把所有相同排序值的行全纳入窗口）
常见错误是写 RANGE 却没确认排序列是否唯一或是否支持该类型——比如用字符串列做 RANGE，多数数据库直接报错：ERROR: RANGE frame with non-numeric ORDER BY expression
聚合函数作为窗口函数时，GROUP BY 和 WHERE 的执行顺序决定你能看到什么
窗口函数只在SELECT 阶段生效，它作用于：
- 已经经过 WHERE 过滤
- 已经经过 GROUP BY（如果存在）聚合后的结果集（注意：此时每组只剩一行，PARTITION BY 必须与 GROUP BY 字段一致，否则逻辑矛盾）
这意味着：
- 你想算“每个用户最近3笔订单的平均金额”，不能先
GROUP BY user_id再开窗；得保留明细行，用PARTITION BY user_id ORDER BY order_time+ROWS BETWEEN 2 PRECEDING AND CURRENT ROW - 如果误把
WHERE status = 'completed'写成HAVING，窗口函数根本收不到数据
真正容易被忽略的，是 OVER() 的绑定时机——它不参与逻辑查询顺序的前半段，只在最后“贴结果”。写错位置（比如塞进 WHERE 或 GROUP BY），数据库直接报语法错：WINDOW function is not allowed here。
