window子句是postgresql中显式命名窗口定义的正式机制，用于在多个窗口函数中复用同一窗口框架，提升可读性与维护性，且性能与直接定义无差异。
WINDOW子句的基本写法和复用逻辑
PostgreSQL 的 WINDOW 子句不是语法糖，而是显式命名窗口定义的正式机制——它让同一个窗口框架能在多个窗口函数中被反复引用，避免重复写冗长的 ORDER BY、PARTITION BY 或 FRAME 子句。
关键点在于：定义在 WINDOW 子句里的名称只作用于当前查询语句，不能跨查询复用；且必须出现在 SELECT 列表或 ORDER BY 之前（即紧接在 FROM 后）。
常见错误是把 WINDOW 当成变量赋值，试图在子查询或 CTE 中引用外部定义的窗口名——这不行，每个查询需独立声明。
如何正确声明并引用多个命名窗口
使用 WINDOW 关键字后跟逗号分隔的 name AS (window_definition) 列表即可。每个 window_definition 和直接写在函数后的括号内容完全等价。
WINDOW w1 AS (PARTITION BY category ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)WINDOW w1 AS (ORDER BY id), w2 AS (PARTITION BY status ORDER BY updated_at)- 引用时直接在函数里写
ROW_NUMBER() OVER w1，而不是ROW_NUMBER() OVER (w1)（括号会报错）
注意：窗口名不支持表达式或变量拼接，也不能用双引号包裹（除非含特殊字符，但不推荐）。
与直接写窗口定义相比的性能和可读性差异
语义上完全等价，PostgreSQL 查询规划器会做相同优化，不会因使用 WINDOW 子句而额外计算窗口框架。性能无差异，但可读性和维护性提升明显。
典型适用场景：
- 同一查询中多个函数依赖相同分区+排序逻辑，比如同时计算
RANK()、COUNT(*)、AVG(sales)over 某维度 - 需要对比不同帧范围的结果，如
SUM(x) OVER w_rowsvsSUM(x) OVER w_range，此时两个命名窗口可清晰区分 - SQL 被动态拼接或模板化时，命名窗口比重复写长定义更易替换和校验
容易忽略的是：若某窗口定义中用了别名列（如 SELECT a AS x FROM t WINDOW w AS (ORDER BY x)），PostgreSQL 允许，但部分旧版本（
嵌套查询和CTE中WINDOW子句的作用域限制
WINDOW 子句只对所在查询有效，不能被外层或内层查询继承。这意味着：
- 在 CTE 中定义的
WINDOW，主查询无法访问 - 子查询（如
SELECT ... FROM (SELECT ... WINDOW w AS (...)) s）中的WINDOW仅对该子查询生效 - 若需多层复用，只能每层单独声明；或者把核心窗口逻辑提取为视图（但视图里不能带
WINDOW子句）
一个常被卡住的点：试图在 HAVING 或 WHERE 中引用窗口函数结果——无论是否用 WINDOW 命名，都得先用子查询或 CTE 提取，因为窗口函数执行阶段晚于这些子句。
