WINDOW子句通过一次定义、多处引用，避免SQL Server重复解析相同PARTITION BY和ORDER BY表达式，提升计划缓存命中率与执行效率，且必须设置数据库兼容性级别为160才可用。
WINDOW子句如何避免重复解析PARTITION BY和ORDER BY
SQL Server 每次遇到一个 OVER() 子句，都要独立解析其中的 PARTITION BY 和 ORDER BY 表达式。当多个窗口函数共享同一逻辑（比如都按 dept_id 分组、按 hire_date 排序），重复书写不仅易错，还会让查询优化器多次处理相同结构，降低计划缓存命中率。
使用 WINDOW 子句后，这部分定义只写一次、只解析一次。执行计划中对应窗口元数据也只生成一份，内存和 CPU 开销更可控——尤其在 ORDER BY 含多字段或嵌套表达式时，差异明显。
- 旧写法：每个
OVER (PARTITION BY a, b ORDER BY c DESC, d)都触发完整语法树构建 - 新写法：
WINDOW w AS (PARTITION BY a, b ORDER BY c DESC, d)仅解析一次，后续全引用w - 不支持动态表达式：
WINDOW定义里的列名、常量必须静态可推导，不能是变量或参数
为什么WINDOW子句必须搭配兼容性级别160
WINDOW 是 SQL Server 2022 引入的原生语法关键字，解析器在兼容性级别低于 160 时根本不识别它。不是警告，而是直接报错：Incorrect syntax near 'WINDOW'。
升级后无法降级回 150 或更低，所以操作前要确认业务兼容性：
- 执行
ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL = 160是硬性前提 - 检查当前级别：
SELECT compatibility_level FROM sys.databases WHERE name = 'YourDB' - 某些隐式类型转换行为会变化，尤其是涉及
datetime和字符串拼接的旧逻辑，需回归测试
WINDOW定义能嵌套或复用吗
可以基于已有命名窗口追加框架（ROWS / RANGE），但不能覆盖其 PARTITION BY 或 ORDER BY。
例如：WINDOW w AS (PARTITION BY dept_id ORDER BY hire_date) 定义基础窗口；后续可用 ROW_NUMBER() OVER w 或 SUM(salary) OVER (w ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) —— 后者是在 w 基础上叠加行边界，不是重定义。
- 不允许：
WINDOW w2 AS (w ORDER BY salary)（试图改排序） - 不允许：
WINDOW w2 AS (PARTITION BY region ORDER BY hire_date)（与w冲突） - 允许：
WINDOW w_sum AS (w ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)
容易被忽略的语法位置限制
WINDOW 子句必须放在 SELECT 关键字之后、FROM 之前，且不能出现在子查询或 CTE 的内部 SELECT 中。
常见误写：SELECT ... FROM (SELECT ... WINDOW w AS ...) t 会报错；正确写法是把 WINDOW 放在外层 SELECT 的开头位置。
另外，WINDOW 定义的作用域仅限当前 SELECT，跨 UNION 或 CTE 不可见——这点和 CTE 的作用域规则一致，但比很多人直觉中“像变量一样全局可用”要严格得多。
