SQL Server 2022 窗口函数执行效率提升源于 WINDOW 子句、兼容性级别 160 和查询优化器协同优化；WINDOW 复用窗口定义降低解析开销，但需显式升级兼容级别且不可回退，索引缺失仍会导致排序溢出。
SQL Server 2022 的窗口函数本身没加新函数，但执行效率确实变快了——关键在 WINDOW 子句、兼容性级别 160 和底层查询优化器的协同作用。
为什么用了 WINDOW 子句就更快？
以前写多个窗口函数，比如 ROW_NUMBER() 和 AVG() 都要重复写一遍 PARTITION BY dept_id ORDER BY salary DESC，SQL Server 每次都得重新解析、校验、生成窗口元数据。现在用 WINDOW 子句只定义一次，所有引用都复用同一份结构：
SELECT dept_id, salary, ROW_NUMBER() OVER w AS rn1, AVG(salary) OVER w AS avg1 FROM employee WINDOW w AS (PARTITION BY dept_id ORDER BY salary DESC);
- 解析开销降为原来的 1/N（N 是同构窗口函数个数）
- 执行计划里窗口框架只存一份，减少内存占用和 CPU 解析时间
- 当
ORDER BY含多字段或带RANGE BETWEEN时，收益更明显
WINDOW 子句必须搭配兼容性级别 160
WINDOW 关键字在低于 160 的兼容级别下直接报错：Incorrect syntax near 'WINDOW'，不是警告，是解析器根本不认识它。
- 升级命令必须显式执行：
ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL = 160 - 升级后无法回退到 150 或更低（除非重建数据库）
- 旧版隐式类型转换规则可能变化，建议回归测试关键查询
- 确认当前级别：
SELECT compatibility_level FROM sys.databases WHERE name = 'YourDB'
智能查询处理（IQP）对窗口函数的间接影响
IQP 2.0 不专为窗口函数设计，但在参数化排序或动态分区场景下会起效：
- 当
ORDER BY字段来自变量（如@sort_col），且不同参数值导致数据分布差异大时，参数敏感计划（PSP）可能为不同参数生成独立执行计划 - 避免“一刀切”排序——比如按
created_at排序快，但按amount排序时大量溢出磁盘，PSP 可分别优化 - 自适应连接等 IQP 特性不直接影响窗口计算，但能提升含窗口函数的复合查询整体并行效率
真正容易被忽略的是：WINDOW 子句只解决“重复定义”开销，不解决排序本身慢的问题。如果 PARTITION BY 和 ORDER BY 列没建合适索引，照样会排序溢出到 tempdb——这点和旧版本完全一样，别误以为开了 160 就自动变快。
