window子句用于复用重复的partition by、order by和rows/range定义，必须紧接在from（含join、where）之后、order by之前，作用域仅限当前查询层级，不提升性能但显著增强可维护性。
因为 WINDOW 子句把重复的 PARTITION BY、ORDER BY 和 ROWS/RANGE 框架抽成一个命名窗口，后续所有 OVER w 都直接引用，避免手写多遍——只要改一处定义，所有调用自动同步，错一个括号、少一个逗号的风险就没了。
WINDOW 子句必须放在 FROM 之后、ORDER BY 之前
它不是函数，也不是 SELECT 的一部分，位置错就直接报语法错误。比如在 PostgreSQL 或 MySQL 8.0+ 中：
SELECT name, SUM(salary) OVER w, AVG(age) OVER w FROM employees WINDOW w AS (PARTITION BY dept ORDER BY hire_date) ORDER BY name;
上面这个顺序不能颠倒：WINDOW 必须紧接在 FROM（含 WHERE、JOIN）之后、ORDER BY 之前；塞进 SELECT 列表里或丢到末尾，都会触发 INVALID_SQL_SYNTAX。
- MySQL 8.0+ 允许
WINDOW出现在WHERE后，但不推荐——容易被误读为“条件相关” - PostgreSQL 要求更严格：必须在
FROM后、GROUP BY前，且不能和HAVING混在一起 - SQL Server 2022 只有兼容级别 ≥160 才认这个关键字，否则报
Incorrect syntax near 'WINDOW'
复用 ≥2 次才值得用 WINDOW 子句
只用一次 OVER w，反而增加阅读负担：别人得往上翻找 WINDOW w AS () 定义，不如直接写 OVER (PARTITION BY ...) 直观。
- 真正省事的场景是同时用
ROW_NUMBER()、SUM() OVER、LAG()等多个函数，且它们共享同一套分区和排序逻辑 - 如果某个函数需要不同排序（比如一个按时间升序、另一个要降序），就得另起一个窗口名，如
w_asc和w_desc，不能靠修改引用去覆盖 - 别指望
WINDOW w2 AS (w1 ORDER BY other_col)这种继承写法——PostgreSQL 支持，MySQL 不支持，SQL Server 完全不认
命名窗口不能跨 CTE 或子查询生效
你在主查询写的 WINDOW w AS ()，进不了 WITH t AS (SELECT ...) 里面。CTE 内部要用，必须在里面重新定义。
- 嵌套三层以上时，每个层级都得重写一遍，或者把共用逻辑提前到最外层 CTE 中预计算（但可能牺牲性能）
- 别名冲突很常见：如果表里有列叫
w，或用了FROM t AS w，再定义WINDOW w AS ()，PostgreSQL 会直接拒绝，MySQL 可能静默覆盖导致行为异常 -
WINDOW定义中不能用列别名，只能用原始列名或表达式（如created_at::date），否则报UNRESOLVED_WINDOW_REFERENCE
最容易被忽略的是：即使写了 WINDOW，如果只在一个地方引用、其余仍手写 OVER ()，那等于白搭；还有人以为它能提升运行速度——其实优化器最终展开成等价语句，执行计划完全一样，纯为可维护性服务。
