Azure SQL DB中SQL LAG语句运行过慢问题求助

这个问题我之前也碰到过——明明不加LAG时几秒就能返回50条结果，加个窗口函数直接慢到5分钟，核心问题大多出在查询优化器的执行计划选择偏差上，咱们试试这几个实用解决方案：

1. 先过滤再应用窗口函数（最直接有效） #

既然过滤后的数据集只有50条，那咱们先把这部分结果单独提取出来，再在这个极小的数据集上用LAG。用CTE（公共表表达式）就能轻松实现：

WITH FilteredRecords AS (
    SELECT 
        H.[StorageItemId], 
        H.[FullyQualifiedName], 
        V.DateTime, 
        V.Value 
    FROM [dbo].[History_StorageItem] AS H 
    JOIN [dbo].[History_Integer] AS V 
        ON H.StorageItemId = V.StorageItemId 
    WHERE 
        H.FullyQualifiedName LIKE '%.Flt_No' 
        AND V.QualityDetail = 192 
        AND V.DateTime > GETDATE() - 8
)
SELECT 
    StorageItemId, 
    FullyQualifiedName, 
    DateTime, 
    Value,
    LAG(Value) OVER (ORDER BY DateTime) AS prevVal
FROM FilteredRecords;

这么做相当于明确给SQL优化器指路：先完成JOIN和过滤拿到小数据集，再在这50条数据上做窗口排序，完全避免了对大表做全量排序的巨额开销。

2. 优化索引，让过滤和排序更顺畅 #

检查一下History_Integer表的索引配置，如果没有合适的复合索引，优化器可能要做大量的全表扫描或临时排序。建议创建包含关联、过滤、排序所需字段的复合索引：

CREATE NONCLUSTERED INDEX IX_HistoryInteger_StorageItemId_DateTime_QD
ON [dbo].[History_Integer] (StorageItemId, DateTime, QualityDetail)
INCLUDE (Value);

这个索引能帮优化器快速定位符合条件的记录：通过StorageItemId关联表、QualityDetail过滤无效数据、DateTime筛选时间范围，同时INCLUDE里的Value避免了回表查询；窗口函数的ORDER BY DateTime还能直接利用索引的顺序，减少额外排序的消耗。

至于History_StorageItem表的FullyQualifiedName，因为是后缀匹配（%.Flt_No），普通索引没法直接生效，但如果这个表数据量不大，基本不会影响性能。

3. 强制重新生成执行计划 #

有时候SQL优化器会复用旧的执行计划（比如没加LAG时的计划），导致加了LAG后选择了低效的执行路径。可以在查询末尾加上OPTION(RECOMPILE)强制优化器重新计算计划：

SELECT 
    H.[StorageItemId], 
    H.[FullyQualifiedName], 
    V.DateTime, 
    V.Value,
    LAG(V.Value) OVER (ORDER BY V.DateTime) AS prevVal 
FROM [dbo].[History_StorageItem] AS H 
JOIN [dbo].[History_Integer] AS V 
    ON H.StorageItemId = V.StorageItemId 
WHERE 
    H.FullyQualifiedName LIKE '%.Flt_No' 
    AND V.QualityDetail = 192 
    AND V.DateTime > GETDATE() - 8
OPTION(RECOMPILE);

这样优化器会根据当前查询的完整逻辑（包括LAG函数）重新评估，大概率会选择先过滤再做窗口函数的最优路径。

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