window子句用于避免重复书写相同over()定义，提升sql可读性与可维护性；必须在from后、order by前定义，仅限当前查询层级使用，复用≥2次时推荐使用。
重复写一模一样的 OVER() 子句，不仅容易出错，还让 SQL 变得又长又难维护——WINDOW 子句就是专治这个的。
什么时候必须用 WINDOW 子句？
当你在同一个查询里，对多个窗口函数使用完全相同的分区、排序和框架定义时，就该上 WINDOW 子句了。比如同时算部门内累计销售额、移动平均、排名，全都要按 PARTITION BY department, EXTRACT(YEAR_MONTH FROM date) + ORDER BY date 走。
- 不写
WINDOW：每个函数都得重复一遍OVER (PARTITION BY ... ORDER BY ...)，少打一个逗号或括号就报错 - 写了
WINDOW：一次定义，多处引用，改逻辑只动一处 - 特别适合嵌套较深、含 3 个以上窗口函数的报表类查询
WINDOW 子句的语法陷阱
它不是函数，不能出现在 SELECT 列表里，必须放在查询末尾、ORDER BY 之前，且只能被当前查询层级的窗口函数引用。
- 错误写法：
SELECT ..., SUM(x) OVER w FROM t WINDOW w AS (...)——WINDOW必须在FROM后、ORDER BY前，不能跟在SELECT后面 - 正确位置：
SELECT ..., SUM(x) OVER w, AVG(y) OVER w FROM t WINDOW w AS (PARTITION BY a ORDER BY b) - 别名不能和列名/表名冲突，否则部分数据库（如 PostgreSQL）会报错；MySQL 8.0+ 支持，但 SQL Server 不支持
WINDOW子句（得靠 CTE 模拟）
命名窗口 vs 多次写 OVER：性能有差别吗？
没有运行时性能差异。数据库优化器会把命名窗口展开成等价的重复定义，最终执行计划一样。它的价值纯在可读性和可维护性。
- 好处是：修改分区逻辑时，不会漏掉某个
OVER里的字段；加ROWS BETWEEN框架时，所有引用自动同步 - 坏处是：过度抽象可能让新人看不懂——比如看到
SUM(sales) OVER monthly却找不到monthly定义在哪，所以建议把WINDOW块紧挨着FROM写，别扔到查询最底下 - 如果只用一次，硬写
OVER更直白；复用 ≥2 次，无脑上WINDOW
真正容易被忽略的是：命名窗口不能跨 CTE 或子查询复用。你在外部查询定义的 WINDOW w AS (...)，进不去 WITH t AS (SELECT ...) 里面。想复用就得把定义提到最外层，或者干脆在 CTE 里重写一遍。
