窗口函数性能瓶颈主要源于ORDER BY列缺失索引、低基数PARTITION BY导致内存溢出、ROWS/RANGE误用、嵌套重复计算。需为ORDER BY列建复合索引，避免低区分度分区，优先用ROWS框架，通过CTE复用窗口结果。
ORDER BY 字段没索引，窗口函数会变慢
SQL Server 执行 ROW_NUMBER()、SUM() OVER(... ORDER BY ...) 这类函数时，如果 OVER 子句里用了 ORDER BY 但对应列没索引，就会触发排序操作（Sort operator），在执行计划里看到红色警告或高成本的 Sort 节点。尤其当分区大、行数多时，性能断崖式下降。
实操建议：
- 对所有出现在
OVER (PARTITION BY X ORDER BY Y)中的Y列，建复合索引：优先INCLUDE窗口计算需要的其他列（比如Amount） - 若同时有
PARTITION BY A, B和ORDER BY C，索引应为(A, B, C) INCLUDE (D, E)—— 不要颠倒顺序 -
RANGE BETWEEN对非唯一排序列更敏感，没索引时容易退化成全扫描；ROWS BETWEEN相对稳定，但依然依赖排序效率
PARTITION BY 分区过大导致内存溢出
窗口函数会在内存中维护每个分区的状态。如果 PARTITION BY 字段区分度低（比如只按 Status 分，只有 3 个值），整个表被压成 3 个巨分区，SQL Server 可能因内存不足降级到磁盘工作区（Spill to TempDB），IO 暴涨，查询从秒级变成分钟级。
实操建议：
- 用
SELECT COUNT(*) GROUP BY [partition_col]检查分区大小分布，单个分区超 100 万行就要警惕 - 避免用低基数列单独做
PARTITION BY；必要时加辅助字段组合，例如PARTITION BY YEAR(OrderDate), CustomerID - SQL Server 2019 默认内存授予基于统计信息估算，若实际数据倾斜严重，可加
OPTION (QUERYTRACEON 9481)或升级统计信息后更新
ROWS vs RANGE 框架选错，引发意外计算
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是物理行偏移，稳定高效；而 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是按排序值“等价聚合”，遇到重复排序值会把所有同值行全纳入当前窗口——这可能让累计和突然跳变，且引擎必须扫描更多行来确认边界。
实操建议：
- 时间序列或主键递增场景，一律用
ROWS—— 它不依赖值唯一性，性能可预测 - 只有明确需要“同值同行一起算”时才用
RANGE，例如按评分分档统计人数，且评分字段已建索引 -
RANGE在datetime2或浮点列上极易出错，SQL Server 2019 不支持RANGE与LEAD/LAG混用，会报错Msg 116
嵌套窗口函数或多次引用同一窗口，重复计算
写成这样：SUM(Amount) OVER (PARTITION BY Dept ORDER BY Date) AS s1, AVG(Amount) OVER (PARTITION BY Dept ORDER BY Date) AS s2，SQL Server 2019 不会复用窗口结果，而是分别执行两次排序+聚合，CPU 和内存开销翻倍。
实操建议：
- 用 CTE 预先计算一次窗口，再 SELECT 多个衍生字段：
WITH w AS (SELECT *, SUM(Amount) OVER (...) AS sum_amt FROM t) SELECT sum_amt, sum_amt * 0.1 FROM w - 避免在 WHERE 或 JOIN 条件里直接用窗口函数结果（如
WHERE ROW_NUMBER() OVER (...) = 1），改用 CTE + 外层过滤 - SQL Server 2019 不支持
QUALIFY（那是 2022+ 的特性），别指望靠它简化逻辑
窗口函数本身不慢，慢的是没对齐它的运行机制：它依赖排序稳定性、内存局部性和框架语义一致性。最容易被忽略的，是把 ORDER BY 当成可有可无的装饰项——其实它几乎总是性能瓶颈的起点。
