复杂查询的性能测量

Question

现在我已经通过检查所有这些小部分并调查它们缺失的索引、索引设计、查询列顺序、连接与存在，从而过度使用了一个非常非常复杂的 sql 语句......我想看看我的工作的真正效果.

该查询使用 CTE 并执行八个 UNION 操作。我会给你一个非常修改的版本，给你一个基本的想法：

declare @O  UniqueIdentifier
set @O  = '11111111-1111-4c97-bce8-db988e11a9c1'
declare @US UniqueIdentifier
set @USK = '22222222-2222-433c-8721-b432de1b2cc5'

;WITH JACK AS (select iNumber from dbo.Tab1)
,GR AS (SELECT cats From dbo.tK)
,DATAROWS AS (
    SELECT ROW_NUMBER() OVER( ORDER BY Number DESC) AS RIX, SpecCol
    FROM dbo.MyBaseTable
        WHERE SpecialCol IN 
        (               
            SELECT flux as i FROM dbo.T6 as O WHERE Wash = @O  AND GiveHint = 1 AND Extended = 1 AND Burned = 0 
            UNION
            SELECT figure FROM dbo.T9  WHERE Wash = @O  AND GiveHint = 2 AND Extended = @USK AND ix in (select iNumber from JACK)
            UNION
            SELECT randomid FROM dbo.T7 WHERE Wash = @O AND GiveHint = 0 and frame = 8 and pieces in (select kids from GR)
            -- ...several more unions....
            /* end of union */
        ) --END OF IN
) --end of DATAROWS

SELECT * FROM dbo.view1 
inner join DATAROWS on DATAROWS.i = dbo.view1.ID

首先，我将新旧版本的查询包装到存储过程中并WITH RECOMPILE在 SP 中使用。

与同时执行 100 次查询运行时相比，运行 sp 没有明显差异。所以我怀疑数据缓存影响最大。如果数据在缓存中，查询计划的差异可能会产生微小的差异，因为无论如何 IO 时间都很短。

这就是为什么我决定尝试核选项。我已使用刷新数据缓存和计划缓存

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO
DBCC FREEPROCCACHE
GO

第一次执行后，程序运行了大约 40 秒，而在我再次删除缓存后，旧的程序运行了大约 13 分钟。这看起来很神奇。

第一次和初始执行后的运行时间基本相同…… 两个版本大约 5 秒。

所以现在我想知道现实生活中是否有任何真正的改善？有人会注意到这种变化吗？我测量的方式正确吗？

版本：SQL 2008 r2 标准版。埃德。

原始查询结果（不清除任何缓存）

SQL Server parse and compile time: 
   CPU time = 1785 ms, elapsed time = 1785 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(10 row(s) affected)
Table 'SO'. Scan count 20, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 20, lob physical reads 0, lob read-ahead reads 0.
Table 'ST'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'OPr'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'U'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Su'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'vOS'. Scan count 14, logical reads 111, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'O'. Scan count 98, logical reads 48381, physical reads 32, read-ahead reads 2486, lob logical reads 105, lob physical reads 0, lob read-ahead reads 0.
Table 'Wo'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'MW'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'MR'. Scan count 2, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'OPo'. Scan count 430768, logical reads 1295180, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Wt'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CWM'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CRM'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'UGU'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'URR'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'UGM'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 2762 ms,  elapsed time = 3073 ms.

优化查询结果：（不清除任何缓存）

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 1975 ms, elapsed time = 1975 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(10 row(s) affected)
Table 'SO'. Scan count 20, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 20, lob physical reads 0, lob read-ahead reads 0.
Table 'ST'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'OPr'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'U'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Su'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'vOS'. Scan count 2, logical reads 63, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'O'. Scan count 50, logical reads 24069, physical reads 0, read-ahead reads 0, lob logical reads 105, lob physical reads 0, lob read-ahead reads 0.
Table 'Wo'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'MW'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'MR'. Scan count 2, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'OPo'. Scan count 430768, logical reads 1295180, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Wt'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CWM'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CRM'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'UGU'. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'URR'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'UGM'. Scan count 2, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 2839 ms,  elapsed time = 7013 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

问题是：如果在现实生活中缓存不会显示/允许优化查询的任何优势与关于运行时的原始查询相比是否值得付出努力，因为一切都可能在缓存中？

Answer 1

第一次执行后，程序运行了大约 40 秒，而在我再次删除缓存后，旧的程序运行了大约 13 分钟。这看起来很神奇。

因此，新公式似乎具有更好的冷缓存性能，这很可能是由于更积极的预读 I/O。例如，这通常适用于通过点查找进行特征（范围）扫描的计划。

所以现在我想知道现实生活中是否有任何真正的改善？有人会注意到这种变化吗？

那要看情况了。如果数据和索引页的工作集适合内存，即使在考虑了其他需求（例如排序和散列、计划缓存...）之后，也可能不会——除非在重新启动后的加速期间（或者如果缓冲区由于某种原因缓存被刷新）。

也就是说，事情可以而且确实会随着时间而改变。随着数据量的增长和内存需求的扩大（两者都倾向于这样做），至少某些查询需要从持久存储中获取信息的可能性会增加。更有效地使用预读的查询可能在这种情况下受益，人们可能会“注意到”。

此外，当前查询的冷缓存性能很差。谁知道它什么时候可能会遇到性能悬崖（目前仅通过访问内存数据来掩盖）。为什么要冒这个险？

我测量的方式正确吗？

每个人都有自己对性能测试的个人偏好。当然，将查询包装在一个过程中是合理的，特别是如果它是在生产中使用的方式。我不太相信需要WITH RECOMPILE. 这可能会产生意想不到的副作用，并且可能不是预期的多数情况（存储过程促进计划重用）。

STATISTICS IO, TIME 比较

提供的数据表明，新查询在几个方面更好。表vOS和上的扫描计数较低O，逻辑读取也较少。桌子CWM，CRM，UGU，URR并UGM不会在所有的扫描。也就是说，结果可能无法直接比较，因为第二组根本没有预读。您需要确保测试是公平的，并尽可能使用相同的起始条件。