PostgreSQL 14+、MySQL 8.0.2+ 和 SQL Server 2022+（兼容级别≥160）真正支持 WINDOW 子句，其中 PostgreSQL 支持最完整，MySQL 仅限 SELECT 顶层且不支持动态帧，SQL Server 不支持在 UPDATE/DELETE 中使用，SQLite、Oracle 及旧版 SQL Server 完全不支持。
SQL 标准确实在 2016 年（ISO/IEC 9075:2016）引入了 WINDOW 子句，但它不是所有数据库都支持，且行为细节有差异——PostgreSQL 支持最完整，MySQL 8.0+ 和 SQL Server 2022+ 仅部分支持，而 SQLite、Oracle、旧版 SQL Server 完全不识别该语法。
哪些数据库真正支持 WINDOW 子句？
只在明确声明支持的引擎中才能用，否则会报错 ERROR: syntax error at or near "WINDOW" 或类似解析失败提示。实际可用情况如下：
- PostgreSQL 14+：完整支持，可定义命名窗口并复用
ORDER BY、PARTITION BY、FRAME等 - MySQL 8.0.2+：支持
WINDOW关键字，但仅限于SELECT顶层，不能嵌套在子查询或 CTE 中；且不支持ROWS BETWEEN的动态帧定义 - SQL Server 2022+：支持
WINDOW子句，但要求兼容级别 ≥ 160，且不支持在UPDATE或DELETE中使用 - SQLite、Oracle 21c 及更早版本、PostgreSQL
WINDOW 子句怎么写才不报错？
核心是把重复的 OVER 内容提取为具名窗口，再在函数中引用。注意三点：窗口名必须唯一、定义位置必须在 SELECT 列表之前、不能带括号参数。
正确写法示例（PostgreSQL）：
SELECT id, value, AVG(value) OVER w1 AS avg_by_group, SUM(value) OVER w1 AS sum_by_group, ROW_NUMBER() OVER w2 AS rn_in_group FROM data WINDOW w1 AS (PARTITION BY category ORDER BY created_at), w2 AS (PARTITION BY category ORDER BY created_at DESC);
常见错误包括：
- 在
WINDOW定义里写AVG(value)—— 不合法，窗口定义只含分区、排序、帧，不含函数 - 把
WINDOW放在WHERE后面 —— 必须紧接在FROM/JOIN之后、SELECT列表之前 - 窗口名重复，如两个
w1—— 解析器会报duplicate window name
为什么用了 WINDOW 还是没简化代码？
因为很多人误以为它能消除所有重复，其实它只解决“相同 OVER 子句多次出现”的场景。以下情况它帮不上忙：
- 不同函数需要不同帧（比如一个要
ROWS UNBOUNDED PRECEDING，另一个要RANGE CURRENT ROW）—— 必须定义两个窗口 - 部分函数需排序、部分不需要（如
COUNT(*) OVER (PARTITION BY x)vsROW_NUMBER() OVER (PARTITION BY x ORDER BY y)）—— 排序字段不一致，无法共用 - 想在
WHERE或HAVING中引用窗口函数结果 —— 窗口函数本身不能出现在这些子句，WINDOW不改变这一限制
此时不如用 CTE 预计算，比硬套 WINDOW 更清晰。
替代方案：没有 WINDOW 时怎么减少重复？
在不支持 WINDOW 的数据库（如 MySQL 5.7、SQL Server 2019），只能靠结构化重写：
- 用 CTE 提前算好分区键和排序序号：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY cat ORDER BY ts) AS rn, ...) - 把常用
PARTITION BY字段提前生成伪列，再在各函数中复用：SELECT ..., SUM(v) OVER (PARTITION BY cat_grp), AVG(v) OVER (PARTITION BY cat_grp) - 应用层拼 SQL 时做模板替换（如 Python f-string 或 Jinja2），避免手写多遍
OVER
别指望一条通用语法解决所有问题——窗口定义的语义粒度（分区/排序/帧）一旦有任一不同，就必须拆成独立 OVER，这是 SQL 执行模型决定的，绕不开。
