PostgreSQL支持在单个WINDOW子句中用逗号分隔定义多个命名窗口（如w1、w2），每个可被多次引用，但作用域仅限当前查询，不可跨CTE、视图或后续查询复用。
PostgreSQL 不支持在单个查询中用 WINDOW 子句“定义多个复用窗口”后再统一引用——WINDOW 子句本身只允许定义一个具名窗口，且该定义仅对当前查询生效；但你可以通过重复声明多个 WINDOW 子句项（用逗号分隔）来实现多窗口复用。
WINDOW 子句语法只允许一个子句，但可包含多个命名窗口定义
很多人误以为 WINDOW 是一个只能写一次、只能定义一个窗口的“语句”，其实不然。PostgreSQL 的 WINDOW 子句是一个复合结构：它以关键字 WINDOW 开头，后跟一个或多个用逗号分隔的 name AS (window_definition) 项。
这意味着你完全可以一次性定义 w1、w2、w3 多个窗口，在后续的 SELECT 列表或 ORDER BY 中反复使用它们。
-
WINDOW w1 AS (PARTITION BY category ORDER BY ts), w2 AS (ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)是合法且常用写法 - 每个命名窗口在同一个查询中可被多次引用，比如
ROW_NUMBER() OVER w1和SUM(x) OVER w1可共存 - 不能跨查询复用——下一条
SELECT必须重新声明WINDOW，视图或 CTE 中也无法继承上层的窗口定义
为什么不能把窗口定义抽成“变量”或“宏”？
PostgreSQL 没有提供类似 SQL/PSM 中的窗口模板机制，也没有 CREATE WINDOW 这类 DDL。窗口定义本质上是查询执行计划的一部分，绑定到具体的数据分区逻辑和排序需求，无法脱离上下文抽象。
常见误解是想写成这样：
WITH window_defs AS (...) SELECT ... OVER w1 FROM ... WINDOW w1 AS (...);
这是无效的——WINDOW 子句不接受 CTE 或子查询输出作为定义源。
- 试图用
PREPARE+ 参数化窗口定义？不行，PARTITION BY和ORDER BY表达式不支持参数占位符（$1） - 想在函数里封装窗口逻辑？只能封装整个查询（返回
SETOF），不能只封装窗口定义 - 视图中定义
WINDOW？语法错误，视图定义不允许出现WINDOW子句
实际写法：一个 WINDOW 子句里塞多个命名窗口
这是最简洁、最可控的方式。只要窗口之间逻辑独立（比如一个按用户分组，一个全表累积），就直接并列声明。
例如统计每个用户的最新订单时间，同时计算全局滚动 7 天订单量：
SELECT user_id, order_time, FIRST_VALUE(order_time) OVER w_user AS first_order_in_user, COUNT(*) OVER w_7days AS orders_last_7days FROM orders WINDOW w_user AS (PARTITION BY user_id ORDER BY order_time), w_7days AS (ORDER BY order_time RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW);
- 两个窗口定义必须写在同一
WINDOW子句内，用逗号分隔，不可拆成两个WINDOW -
w_user用PARTITION BY+ORDER BY，适合行内比较；w_7days用RANGE+ 时间区间，适合时序聚合 - 注意
RANGE对timestamp类型更安全，而ROWS在时间不均匀时可能漏数据
容易踩的坑：别混淆 WINDOW 子句和 OVER 中的内联窗口
你可以不用 WINDOW 子句，直接在每个 OVER 里写完整定义，比如 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)。但这样重复写三遍，不仅冗长，还容易出错。
关键区别在于：
- 内联窗口定义（
OVER (…)）每次都是独立解析，即使内容完全相同，优化器也不保证复用执行计划 - 具名窗口（
OVER w1）让优化器明确知道多个函数共享同一窗口逻辑，可能合并计算步骤，尤其在涉及RANGE或复杂FRAME时更高效 - 如果两个内联窗口只差一个空格或大小写（如
ORDER BY avsORDER BY A），PostgreSQL 视为不同窗口，不会复用
真正需要“复用”的场景，几乎总是应该优先选具名窗口 + 单一 WINDOW 子句声明多个名字。否则所谓“复用”只是心理安慰，不是执行层面的优化。
