结论：window子句必须紧接在from（含join、where等）之后、order by之前，不能出现在select列表或查询末尾，且作用域仅限当前查询层级。
直接说结论：当同一个查询里有 ≥2 个窗口函数用完全相同的 PARTITION BY、ORDER BY 和 ROWS/RANGE 定义时，必须用 WINDOW 子句；否则硬写重复 OVER (...) 不仅易错，改一处漏一处。
WINDOW子句该放在SQL的哪个位置
WINDOW 必须紧接在 FROM（含 JOIN、WHERE 等）之后、ORDER BY 之前，不能塞进 SELECT 列表里，也不能丢到查询末尾。
- 错误写法：
SELECT SUM(x) OVER w FROM t WINDOW w AS (...)——WINDOW出现在SELECT后，语法报错 - 正确写法：
SELECT SUM(x) OVER w, AVG(y) OVER w FROM t WINDOW w AS (PARTITION BY dept ORDER BY date) - 别名
w不能和已有列名、表名冲突，PostgreSQL 会直接拒绝；MySQL 8.0+ 允许但建议加前缀如w_dept_time避免歧义
命名窗口能跨CTE或子查询复用吗
不能。命名窗口的作用域仅限当前查询层级，WITH 子句里的 CTE 看不到外部定义的 WINDOW，反过来也一样。
- 想在 CTE 内复用？必须把
WINDOW w AS (...)写进 CTE 的SELECT语句里，和主查询分开定义 - 嵌套三层以上查询时，每个层级都得重写一遍
WINDOW，或者干脆把共用逻辑提前到最外层WITH中做预计算 - 别指望靠引用另一个窗口来“继承”参数：
WINDOW w2 AS (w1 ORDER BY other_col)在 PostgreSQL 支持，但 MySQL 不支持，SQL Server 根本不认WINDOW关键字
用WINDOW后性能变快了吗
不会。数据库优化器会在执行前把所有 OVER w 展开成等价的完整 OVER (...)，最终执行计划和手写重复版一模一样。
- 它的价值纯在可维护性：改分区字段只需动
WINDOW定义处，不用逐个检查SUM() OVER、ROW_NUMBER() OVER、AVG() OVER - 加
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW框架时，所有引用自动同步，不怕漏写 - 但容易被忽略的是：如果只用一次
OVER，硬写反而更直观；强行套WINDOW w AS (...)反而增加阅读负担
真正卡住人的地方不是语法，而是窗口定义的位置约束和作用域隔离——写完 WINDOW 块后，得立刻确认它离 FROM 够近、没被 GROUP BY 或 HAVING 挡住，且所有引用它的 OVER 都在同一层查询里。
