SQL Server 2022 不支持在子查询中直接使用窗口函数（如 SUM() OVER (...)）作为标量子查询；正确做法是直接在主查询中使用 SUM(amount) OVER (ORDER BY order_date, order_id ROWS UNBOUNDED PRECEDING) 实现累计求和，并确保 ORDER BY 包含唯一列以避免重复值导致的跳变。
SQL Server 2022 中不能用 Windowed 子查询 做累计求和
直接说结论：WINDOWED SUBQUERY 不是合法语法，SQL Server 不支持在子查询中直接声明窗口函数（如 SUM() OVER (...)）并将其作为标量子查询使用。你看到的“Windowed子查询”大概率是混淆了概念——实际能用的是「窗口函数 + 主查询结构」，不是嵌套子查询里套 OVER。
正确写法：用 SUM() OVER () 替代自连接或相关子查询
老式累计求和常靠自连接或相关子查询实现，性能差、逻辑绕。SQL Server 2022 完全支持标准窗口函数，SUM(amount) OVER (ORDER BY order_date ROWS UNBOUNDED PRECEDING) 就是最直接替代方案。
-
ROWS UNBOUNDED PRECEDING比不写更安全——显式定义帧范围，避免 SQL Server 默认行为变化带来的隐性偏差 - 必须搭配
ORDER BY（即使业务上顺序不重要，也得指定；否则报错Window function requires an OVER clause with ORDER BY） - 如果按客户分组累计，加
PARTITION BY customer_id，但注意PARTITION BY优先级高于ORDER BY，别漏掉重置逻辑
常见翻车点：ORDER BY 列含重复值导致累计结果跳变
比如 order_date 是 DATE 类型，多个订单同一天，SQL Server 窗口函数会把它们视为“同一行位置”，导致累计值在该日期内不递增——看起来像卡住了。
- 解决方法：补一个唯一列进
ORDER BY，例如ORDER BY order_date, order_id - 不要用
RAND()或NEWID()做排序依据——破坏确定性，影响可复现性和索引利用 - 检查执行计划：若看到
Sort操作耗时高，说明缺少覆盖索引；建议建索引如CREATE INDEX IX_orders_date_id ON orders(order_date, order_id) INCLUDE (amount);
和旧方案对比：为什么不用相关子查询了
类似这种写法已过时：(SELECT SUM(t2.amount) FROM orders t2 WHERE t2.order_date 。它在 SQL Server 2022 上仍能跑，但问题明显：
- 数据量超 1 万行后，CPU 和逻辑读飙升，因为每行都触发一次独立扫描
- 无法并行化——窗口函数版本默认可并行，子查询版本强制串行
- 无法下推过滤条件，WHERE 放在外部时，子查询仍可能全表扫
真正要警惕的，不是语法会不会写，而是习惯性沿用旧模式去“套”新功能。窗口函数不是子查询的装饰，它是独立的计算模型——帧（frame）、分区（partition）、排序（order）三者缺一不可，少一个就容易出非预期结果。
