T-SQL 中如何高效计算前1440行窗口的High与Low极值？

旧方案性能拉胯的核心原因 #

• 自连接方案：每一行关联前1440行数据，最终会生成1000万×1440行的膨胀中间结果集，数据量直接冲到144亿行，哪怕加了索引，IO和计算量都完全失控，跑2小时都是正常水平
• LAG函数方案：要算1440个值的最大/最小值，得写1440次偏移取数的嵌套表达式，生成的执行计划体积巨大，编译和运行开销都极高
• 游标方案：逐行读取逐行计算，完全浪费了数据库引擎的批量流式处理能力，1000万行的单行交互，光数据fetch的开销就能把运行时间拉到小时级

方案一：原生窗口帧聚合（优先选择，性能最高） #

很多人对窗口函数的认知停留在LAG/LEAD这类偏移取值的函数上，实际上T-SQL的聚合类窗口原生支持固定物理行范围的计算，针对这类固定行数的滚动窗口统计，引擎做了极致的流式扫描优化——整个计算过程只对全表做一次顺序读取，没有额外关联、没有结果膨胀。

前置准备 #

先在时序列上建聚簇索引，避免全表无序扫描：

-- 替换为实际的表名
CREATE CLUSTERED INDEX IX_Metric_Time ON MinuteMetric(TimeStamp);

核心查询逻辑 #

注意窗口的行数校准：总计1440行的统计窗口（包含当前行），对应前置1439行+当前行，避免出现行数偏差算成1441行的情况：

SELECT
    TimeStamp,
    High,
    Low,
    MAX(High) OVER (
        ORDER BY TimeStamp 
        ROWS BETWEEN 1439 PRECEDING AND CURRENT ROW
    ) AS RollingDay_MaxHigh,
    MIN(Low) OVER (
        ORDER BY TimeStamp 
        ROWS BETWEEN 1439 PRECEDING AND CURRENT ROW
    ) AS RollingDay_MinLow
FROM MinuteMetric
ORDER BY TimeStamp;

性能参考：千万级单表规模在常规SSD服务器上，该查询全量跑完通常仅需10-30秒，远低于2小时的性能阈值。

方案二：分块预聚合（适合增量计算场景） #

如果单表规模超过千万级、需要频繁重复计算滚动值，可以用固定块预聚合的方式进一步降低重复计算开销：

• 按1440行的固定长度给全表打块号，每个块预先计算块内的High最大值、Low最小值
• 计算任意行的滚动窗口值时，仅需要合并当前行所在块、前后相邻共3个块的预聚合结果，不需要逐行扫描1440个原始值
• 后续新增数据时，只需要计算最新块的预聚合值即可完成增量更新，不需要全表重跑

关键避坑点 #

• 窗口定义必须使用ROWS BETWEEN关键字，不要使用RANGE BETWEEN：后者是按值范围计算，复杂度远高于按物理行号定义的窗口，性能差几个数量级
• 必须保证TimeStamp列无重复值：如果存在同一时间戳的多行数据，窗口函数的排序结果会不确定，导致计算值偏差
• 结果落库时使用批量INSERT ... SELECT写法，不要逐行插入，避免事务日志开销拖慢整体速度

内容的提问来源于stack exchange，提问作者OverflowStack