Question

我有一个带有2697个记录的SQL Server 2012表，并且该表未编入索引。未来数据将增加至多10万条记录。我没有加入任何其他表来检索记录。最初我创建了一个用户定义的函数来从表中检索记录。

后来我发现一个视图比用户定义的函数更快，因此我为该表创建了一个View。

要了解Query的性能，我包含以下代码以获取我的UDF，VIEW和直接SQL语句的CPU时间和已用时间。

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

当我使用select查询直接从我的表中提取数据时，我获得了以下CPU时间和经过的时间

SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

----结果

Scan count 1, logical reads 1338, 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 = 31 ms,  elapsed time = 4381 ms.

当我使用VIEW时，我将CPU时间和经过时间作为

CREATE VIEW vw_testdata
AS
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

- 结果

Scan count 1, logical reads 1324, 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 = 15 ms,  elapsed time = 5853 ms.

我的UDF以

的形式返回

CREATE FUNCTION [dbo].[fn_DocApproval] (@collegename nvarchar(30) = NULL)
RETURNS TABLE 
AS
RETURN  
(
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata] WHERE CollegeName = ISNULL(@collegename, collagename)
)

- 结果

Scan count 1, logical reads 1338, 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 = 203 ms,  elapsed time = 785 ms.

UDF的直播时间比直接sql和视图少，但CPU时间更长。

但是，与直接SQL和UDF相比，视图中的CPU时间较少。

我想知道我们需要了解哪一个来确定查询的性能。

另外，为什么每次运行相同的查询时，CPU时间和经过时间都会发生变化？

我的架构和示例数据Fiddle

我目前有2697行，而且我无法将它们全部加载到小提琴中。

Answer 1

根据文章SQL Query performance Tuning

SQL Server解析和编译时间：当我们向SQL服务器提交要执行的查询时，它必须解析并编译任何语法错误，并且优化器必须为执行生成最佳计划。 SQL Server解析和编译时间是指完成此预执行步骤所需的时间。如果查看第二次执行的输出，则SQL Server解析和编译时间部分中的CPU时间和已用时间为0。这表明SQL服务器没有花费任何时间来解析和编译查询，因为执行计划在缓存中很容易获得。 CPU时间是指CPU上的实际花费时间，经过时间是指完成解析和编译所花费的总时间。 CPU时间和已用时间之间的差异可能在队列中等待时间以获得CPU周期或等待IO完成。这在性能调优中没有太大意义，因为值会因执行而异。如果您在本节中获得了一致的值，那么可能您将使用重新编译选项运行该过程。

SQL Server执行时间：这是指SQL Server完成已编译计划执行所用的时间。 CPU时间是指在CPU上花费的实际时间，其中经过时间是完成执行的总时间，包括信号等待时间，完成IO操作的等待时间以及将输出传输到客户端所花费的时间.CPU时间可用于基线性能调整。除非您修改查询或数据，否则从执行到执行，此值不会有太大变化。服务器上的负载不会对此值产生太大影响。请注意，显示的时间以毫秒为单位。对于具有相同数据的相同查询，CPU时间的值可能因执行而异，但只有100秒，这只是一秒的一部分。经过的时间取决于许多因素，例如服务器上的负载，IO负载，服务器和客户端之间的网络带宽。因此，在进行性能调整时，始终将CPU时间用作基线。

您在计划中使用的逻辑读取次数越少，查询的效率就越高。

Answer 2

如果使用的是现代服务器，请始终查看“经过时间”而不是“ CPU时间”。在快速多核处理器，多处理器板等时代，影响快速响应而不是处理器的所有其他因素都很重要。碰巧，对于复杂的查询，CPU时间的指示要比总时间大5倍（请检查“执行计划”，然后会有很多并行性）。

CPU时间或经过的时间 - 这实际上意味着SQL Query的性能？

2 个答案: