WINDOW子句必须位于FROM/WHERE之后、GROUP BY/HAVING/ORDER BY之前，仅PostgreSQL、MySQL 8.0+和SQL Server 2022（兼容级别≥160）支持，Oracle及旧版SQL Server不支持，需用CTE或重复定义替代。
直接结论：用 WINDOW 子句能消除重复书写 OVER() 的风险，但只在 PostgreSQL、MySQL 8.0+ 和 SQL Server 2022（兼容级别 ≥160）中有效；Oracle 和旧版 SQL Server 完全不支持，必须换方案。
WINDOW 子句该放在 SELECT 的哪个位置？
它不是独立语句，也不是函数，必须作为 SELECT 查询的一部分，且有严格顺序：
- 只能出现在
FROM/WHERE之后、GROUP BY/HAVING/ORDER BY之前 - 错误写法：
SELECT ..., ROW_NUMBER() OVER w FROM t WINDOW w AS (...)→ 报错，WINDOW不能跟在FROM后面就立刻出现（部分引擎会解析失败） - 正确写法示例：
SELECT id, val, ROW_NUMBER() OVER w, SUM(val) OVER w FROM logs WHERE status = 'ok' WINDOW w AS (PARTITION BY category ORDER BY ts DESC) - 别名（如
w）不能和表别名、列名冲突，PostgreSQL 会报错，MySQL 则可能静默覆盖
哪些数据库真正支持 WINDOW 子句？
支持情况差异大，不能默认“SQL 标准就有”：
- ✅ PostgreSQL：原生支持，无额外条件
- ✅ MySQL 8.0+：支持，但不支持
RANGE框架中的表达式（如RANGE BETWEEN INTERVAL 1 DAY PRECEDING AND CURRENT ROW） - ✅ SQL Server 2022：仅当数据库兼容性级别设为
160时才识别WINDOW关键字；低于该级别直接报Incorrect syntax near 'WINDOW' - ❌ Oracle：至今不支持
WINDOW子句（截至 2026 年），只能靠 CTE 或复制粘贴 - ❌ SQL Server 2019 及更早：语法不识别，改用子查询或临时表预计算
为什么写了 WINDOW 却没生效？常见失效场景
定义了但没被复用，等于白写：
- 在同一个查询里只引用了一次命名窗口（如只用了
ROW_NUMBER() OVER w），而另一个函数仍写AVG(x) OVER (PARTITION BY y ORDER BY z)→ 实际未复用，优化器无法合并逻辑 - 误以为
WINDOW可跨 CTE 生效：外部查询定义的WINDOW w AS (...)，进不了WITH t AS (SELECT ...)内部；CTE 里要用，得在 CTE 内部重新定义 - ORDER BY 表达式不一致：一个写
ORDER BY created_at，另一个写ORDER BY created_at ASC，部分引擎（如旧版 MySQL）不认为二者等价，不会复用排序结果 - 用了
RANGE框架但字段存在大量重复值（如按天截断的日期），导致执行计划仍走多次扫描——这不是WINDOW的问题，而是框架选型不当
不用 WINDOW 子句时怎么避免重复定义？
当目标环境不支持或不适用时，替代方案要务实：
- MySQL 8.0+：确保所有窗口函数的
PARTITION BY和ORDER BY字段完全相同、顺序一致、显式声明ASC/DESC，部分版本可触发内部排序缓存 - SQL Server / Oracle：用 CTE 预计算共用逻辑，例如先算出
PARTITION BY user_id ORDER BY ts下的rn和sum_val，主查询只做引用，避免重复窗口运算 - 所有引擎都适用：对高频使用的排序字段（如
created_at）建索引，减少每次OVER引发的隐式排序开销 - 警惕
COUNT(DISTINCT) OVER ()：并非所有引擎都支持（如早期 Presto 不支持），测试前先查文档
真正容易被忽略的是：命名窗口只解决“写法复用”，不改变执行计划本质；如果分区键基数太低（比如全表只分 2 个区），或 ORDER BY 字段没索引，再简洁的 WINDOW 定义也救不了性能。先看执行计划里的 Sort 和 WindowAgg 节点是否合并，再谈要不要加 WINDOW。
