窗口函数比GROUP BY更适合动态分组统计，因其可在保留明细基础上直接计算分组指标，避免JOIN开销；需用PARTITION BY明确分组边界，ORDER BY对累计类函数必选、排名类虽可省略但易致结果不稳定；主流数据库8.0+/2012+支持，旧版BI直连可能报错；ROW_NUMBER()不适用于时间序列偏移，应以时间字段本身ORDER BY；WHERE不能过滤窗口函数结果。
窗口函数比 GROUP BY 更适合动态分组统计
BI 场景里常要“看每个销售员的业绩，同时显示团队平均值”，用 GROUP BY 得先聚合再 JOIN，既慢又难维护；窗口函数直接在原行上补计算结果，不丢明细，也不引入额外连接开销。
- 必须用
PARTITION BY明确逻辑分组边界，漏写就变成全表计算（比如想按区域算排名却没加PARTITION BY region，结果所有人在一张榜上排） -
ORDER BY在窗口定义里不是可选的——累计类函数（如SUM() OVER (ORDER BY date)）依赖它，但排名类（如RANK()）即使不写也能跑，只是结果不稳定（不同数据库可能返回不同顺序） - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持完整窗口语法；老版本或某些 BI 工具直连（如旧版 Tableau 连 MySQL 5.7）会报错
Window function is not allowed in this context，得提前确认执行环境
ROW_NUMBER() 和 RANK() 混用导致同比/环比错位
做月度环比时，有人用 ROW_NUMBER() 给月份排序后 LAG(value)，结果发现 2023-02 的“上月值”对成了 2023-01，但 2023-03 却对到了 2023-01（跳月）。问题出在 ROW_NUMBER() 按物理顺序编号，而日期有缺失；RANK() 或 DENSE_RANK() 不解决这个问题——它们只管重复值，不管空缺。
- 正确做法是用时间字段本身做偏移：
LAG(value) OVER (ORDER BY year_month)，其中year_month是'2023-01'这样的规范字符串或日期类型 - 如果原始数据里存在重复日期（如一天多条订单），
ROW_NUMBER()会强制打乱顺序，建议先去重或用MAX(value) OVER (PARTITION BY date)聚合后再开窗 - Oracle 中
LAG()默认偏移 1 行，但若ORDER BY结果有并列，实际“上一行”可能不属于同一周期，务必检查排序字段是否唯一且业务语义清晰
WHERE 里不能直接过滤窗口函数结果
写 SELECT sale_amt, RANK() OVER (ORDER BY sale_amt DESC) AS rk FROM sales WHERE rk 会报错 <code>column "rk" does not exist ——因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，窗口函数在 SELECT 阶段才计算，WHERE 根本看不见它。
- 解决方案只有两个：套一层子查询，或改用 CTE。例如：
SELECT * FROM (SELECT *, RANK() OVER (...) AS rk FROM sales) t WHERE rk - CTE 更易读，但某些引擎（如 Presto 0.216）对 CTE 内部窗口函数优化不佳，可能全量扫描；简单场景优先用子查询
- 别试图用
HAVING替代——它只作用于GROUP BY后的聚合结果，和窗口函数无关
ORDER BY 在 OVER() 里加了索引也不一定加速
给 ORDER BY create_time 加了索引，但 COUNT(*) OVER (ORDER BY create_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 还是慢。窗口函数的排序是逻辑层面的，数据库未必能复用已有索引，尤其当 PARTITION BY 存在时，每个分区都要独立排序。
- 优先考虑是否真需要
ROWS BETWEEN ...这种帧定义：如果只是累计求和，ROWS UNBOUNDED PRECEDING可被优化；但带CURRENT ROW或FOLLOWING的范围容易触发临时排序 - PostgreSQL 中，若
PARTITION BY字段有高基数（如用户 ID），且分区数超万，窗口排序开销会指数级上升——这时应评估是否改用物化中间表 - BigQuery 对窗口函数做了深度优化，但要求
ORDER BY字段必须是INT64或TIMESTAMP类型；用STRING存日期（如'20230101'）会导致隐式转换失败，报错Unsupported operand type for OVER: STRING
真正卡住性能的往往不是函数本身，而是没意识到窗口计算发生在最终结果集生成阶段——它无法像普通索引那样提前剪枝，每一行都可能触发重新评估整个分区状态。
