必须将数据库兼容级别设为160或更高，否则sql server 2022不识别window子句，直接报错“incorrect syntax near 'window'”；window须紧接from后、group by前定义，且仅当多个窗口函数共享完全相同的partition by、order by和帧定义时才真正简化代码。
必须先确认数据库兼容级别 ≥ 160，否则 WINDOW 关键字直接报错，不是语法写错，而是引擎根本不识别。
SQL Server 2022 中 WINDOW 子句的启用前提
它不是装上 SQL Server 2022 就自动可用的功能。兼容级别低于 160 时，执行含 WINDOW 的查询会返回：Incorrect syntax near 'WINDOW'。
- 查当前级别：
SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME() - 升级命令（需有 ALTER DATABASE 权限）：
ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL = 160 - 注意：升级后无法降级回 150 或更低；部分旧应用依赖低兼容模式的行为，改之前务必测试
WINDOW 子句在 SELECT 中的合法位置
它必须紧接在 FROM / JOIN / WHERE 之后、GROUP BY / HAVING / ORDER BY 之前。放错位置会导致解析失败或静默忽略（MySQL 行为不一致，SQL Server 则明确报错）。
- ✅ 正确顺序示例：
SELECT ..., ROW_NUMBER() OVER w FROM t WHERE ... WINDOW w AS (PARTITION BY x ORDER BY y) - ❌ 常见错误：把
WINDOW放在SELECT列表之后、FROM之前 → 报错Incorrect syntax near 'WINDOW' - ❌ 在 CTE 外部定义
WINDOW，然后期望 CTE 内部能引用 → 不生效，CTE 是独立作用域，必须在 CTE 内部重新定义
命名窗口复用的边界与陷阱
WINDOW 只消除“完全一致的 OVER 子句”重复，不是万能缩写工具。稍有差异就必须拆成多个窗口定义。
- 排序方向不一致：一个写
ORDER BY ts DESC，另一个写ORDER BY ts ASC→ 必须两个窗口，SQL Server 不认为二者等价 - 帧范围不同：一个要
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，另一个要RANGE CURRENT ROW→ 不能共用，必须分别定义w1和w2 - 字段表达式带函数：如
PARTITION BY YEAR(order_date)vsPARTITION BY order_date→ 不匹配，无法复用 - 别名冲突：若已有表别名
w，再定义WINDOW w AS ...，PostgreSQL 会报错，SQL Server 可能静默覆盖或报标识符冲突
为什么写了 WINDOW 却没减少代码量？
常见原因是“只定义、不复用”，或者误以为它能合并逻辑而非仅简化书写。真正节省维护成本的前提是：同一查询中至少两个窗口函数共享完全相同的分区、排序、帧定义。
- 有效场景：同时用
ROW_NUMBER() OVER w、RANK() OVER w、AVG(sales) OVER w—— 全部指向同一个w - 无效场景：只有一处用
ROW_NUMBER() OVER w，其余仍手写OVER (PARTITION BY x ORDER BY y)→ 白定义，还多占一行 - 性能无提升：它只是语法糖，不改变执行计划；优化器仍按原逻辑生成窗口计算，不会因命名而合并扫描
- 调试更难：出错时错误信息指向
WINDOW定义行，但实际问题可能在某个具体函数调用里（比如LAG()引用了未定义的窗口）
最易被忽略的一点：WINDOW 子句不支持嵌套引用动态帧（如 ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING 中的数字不能是变量或子查询），SQL Server 2022 当前只接受字面量数值——这点和 PostgreSQL 不同，别照搬跨库写法。
