在Microsoft SQL Server中如何优化Lag()窗口函数的查询执行速度？

算力阿峰

2026-10-3

性能差距根因

你观察到的几十倍性能差是SQL Server窗口函数的默认执行机制导致的：

你的#Tmp表的主键是n，聚集索引本身已经完全符合Lag(n) over (order by n)的排序要求，逻辑上确实可以单次流式扫描完成计算
但SQL Server在未显式指定行式窗口框架（ROWS）时，对整数类型排序列会默认使用范围式窗口框架（RANGE），RANGE模式必须依赖Window Spool（窗口假脱机）算子把所有行缓存到tempdb中再计算，千万级数据下tempdb的读写开销直接把耗时拉高了几十倍。

可行优化方案

方案1：场景专属等价改写（性能最优，耗时和直接sum几乎一致）

你的需求是对Lag(n) over (order by n)的结果求和，从逻辑上可以直接等价改写为：

Lag(n)的结果本质是把n列整体下移一行，第一行返回NULL，原表最大的n不会出现在Lag的结果集中，因此Sum(Lag(n)) = Sum(n) - Max(n)

改写后的查询代码：

select @dummy = Sum(Convert(bigint, n)) - Max(Convert(bigint, n)) from #Tmp

这个写法完全避免了窗口函数开销，耗时和你直接sum的1.46秒几乎完全一致。

方案2：通用窗口函数优化（适用于更复杂的窗口计算场景）

如果你的实际业务逻辑比这个示例复杂，必须用Lag函数，可以显式指定行式窗口框架，告诉SQL Server直接利用聚集索引的有序性流式计算，不需要缓存到tempdb：

select
    @dummy = Sum(convert(bigint, n0))
from
    (
    select
        n0 = Lag(n) over (order by n rows between 1 preceding and 1 preceding)
    from
        #Tmp
    ) as Q

加上rows between 1 preceding and 1 preceding的限定后，执行计划会去掉Window Spool算子，改为流式计算，耗时可以降到2秒以内，和直接sum的性能基本持平。