WINDOW子句是SELECT中可选部分，用于定义命名窗口规范以复用PARTITION BY、ORDER BY等，必须位于FROM/WHERE之后、GROUP BY之前，仅作用于当前查询层级。
WINDOW子句的基本写法和作用范围
WINDOW 子句不是独立语句，而是 SELECT 中的可选部分，用于提前定义命名窗口规范，后续的窗口函数可直接引用该名称，避免重复写 ORDER BY、PARTITION BY 等。它只影响当前 SELECT，不跨查询生效。
- 必须放在
FROM和WHERE之后、GROUP BY之前 - 一个
WINDOW定义可以被多个窗口函数复用，比如同时用ROW_NUMBER()、RANK()、AVG() OVER - 窗口名区分大小写（取决于数据库），建议全小写加下划线，如
w_by_time
SELECT id, value, ROW_NUMBER() OVER w_by_time AS rn, RANK() OVER w_by_time AS rk, AVG(value) OVER w_by_time AS avg_val FROM logs WINDOW w_by_time AS (ORDER BY created_at DESC);
常见错误：把WINDOW当成全局声明或误放位置
很多人以为 WINDOW 可以写在查询最开头，或者想在子查询外复用——不行。它仅对当前 SELECT 的 OVER 子句有效。
- 错误：在
WITH子句里定义WINDOW→ 不支持，WINDOW不能出现在 CTE 内部定义中 - 错误：在
GROUP BY之后写WINDOW→ 解析失败，位置非法 - 错误：定义了
w AS (ORDER BY x)，但在OVER w前又写了OVER (ORDER BY x)→ 实际没复用，白定义
另外注意：PostgreSQL 支持 WINDOW 子句；MySQL 8.0+ 支持；SQL Server 和 Oracle 不支持 WINDOW 子句（只能靠复制粘贴或 CTE 拆解）。
替代方案：当数据库不支持WINDOW子句时怎么办
如果用的是 SQL Server 或旧版 MySQL，就无法用 WINDOW 子句，但仍有办法减少重复：
- 把排序逻辑下沉到 CTE，再在外部用多个窗口函数引用同一排序结果
- 使用视图封装带
OVER的计算列（但视图本身不能参数化，灵活性受限） - 在应用层拼 SQL 时做模板化处理（比如用 Jinja 或字符串格式化统一注入
ORDER BY片段）
例如 PostgreSQL 可行，但 SQL Server 必须这样写（重复出现）：
SELECT id, ROW_NUMBER() OVER (ORDER BY ts DESC) AS rn, RANK() OVER (ORDER BY ts DESC) AS rk, SUM(val) OVER (ORDER BY ts DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cumsum FROM events;
性能与可读性权衡：命名窗口是否真能提升执行效率
WINDOW 子句不会改变执行计划，只是语法糖。优化器仍会按需计算每个窗口函数的排序和帧边界，即使它们共享同一个 WINDOW 定义。
- 多个函数共用同一
ORDER BY+ 相同ROWS范围时，多数现代引擎（如 PostgreSQL 14+）会自动复用排序结果，但这是优化器行为，不是WINDOW子句保证的 - 如果一个窗口定义了
PARTITION BY a ORDER BY b，另一个只用ORDER BY b，就不能共用，必须分开计算 - 最容易被忽略的一点：
WINDOW名称本身不携带数据逻辑，一旦改名或重用错，报错信息往往只提示“window not found”，而不是指出哪行OVER引用了不存在的窗口
别指望靠 WINDOW 子句“优化性能”，它解决的是维护性和出错率问题。真正影响性能的是 ORDER BY 字段是否有索引、分区键选择是否合理、帧范围是否过大。
