衡量查询效果：“执行计划查询成本”与“拍摄时间”

Question

我正在尝试确定两个不同查询的相对性能，并有两种测量方法可供我使用：
1.运行两个并查看每个查询的时间 2.运行两者并从实际执行计划中获取“查询成本”

以下是我为查询计时的代码......

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1a
SELECT getDate() - @start AS Execution_Time
GO

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1b
SELECT getDate() - @start AS Execution_Time
GO

我得到的是以下内容：

Stored_Proc     Execution_Time     Query Cost (Relative To Batch)

test_1a         1.673 seconds      17%
test_1b         1.033 seconds      83%

执行时间的结果与查询成本的结果直接相反，但我很难确定“查询成本”实际意味着什么。我最好的猜测是它是Reads / Writes / CPU_Time / etc的集合，所以我想我有几个问题：

1. 是否有一个明确的来源来解释这项措施的含义？

2. 人们使用的其他“查询效果”指标，以及它们的相对优点是什么？


值得注意的是，这是一个中型SQL Server，在MS Server 2003 Enterprise Edition上运行MS SQL Server 2005，具有多个处理器和100多个并发用户。

编辑：

经过一番麻烦后，我设法在该SQL Server上获得了Profiler访问权限，并且可以提供额外信息（支持查询成本与系统资源相关，而不是执行时间本身......）

Stored_Proc    CPU      Reads    Writes   Duration   

test_1a        1313     3975     93       1386
test_1b        2297     49839    93       1207

令人印象深刻的是，花费更多的CPU以及更多的读取需要更少的时间：）

Answer 1

探查器跟踪将其置于透视中。

• 查询A：1.3秒CPU，1.4秒持续时间
• 查询B：2.3秒CPU，1.2秒持续时间

查询B正在使用并行性：CPU＆gt;持续时间 例如，查询使用2个CPU，平均每个1.15秒

查询A可能不是：CPU＆lt;持续时间

这解释了相对于批处理的成本：17％的更简单的非并行查询计划。

优化器确定查询B更昂贵并且将从并行性中受益，即使这需要额外的努力。

请记住，查询B使用100％的2 CPUS（因此4个CPU为50％）大约一秒左右。查询A使用100％的单个CPU 1.5秒。

查询A的峰值较低，但会增加持续时间。 有一个用户，谁在乎？有了100，也许它会有所不同......

Answer 2

SET STATISTICS TIME ON

SELECT * 

FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;

SET STATISTICS TIME OFF;

看到消息标签，它将如下所示：

SQL Server Execution Times:

   CPU time = 0 ms,  elapsed time = 10 ms.

(778 row(s) affected)

SQL Server parse and compile time: 

   CPU time = 0 ms, elapsed time = 0 ms.

Answer 3

  

执行时间的结果与查询成本的结果直接相反，但我很难确定“查询成本”的实际含义。

Query cost是优化程序认为您的查询需要多长时间（相对于总批处理时间）。

优化器会尝试通过查看数据的查询和统计信息，尝试多个执行计划并选择成本最低的计划来选择最佳查询计划。

Here您可能会详细了解它是如何尝试这样做的。

正如您所看到的，这可能与您实际获得的内容有很大不同。

唯一真正的查询性能指标当然是查询实际需要多长时间。

Answer 4

使用SET STATISTICS TIME ON

在您的查询上方

。

在接近结果标签下方，您可以看到消息标签。在那里你可以看到时间。

Answer 5

我理解这是一个老问题 - 但是我想添加一个例子，其中成本相同但一个查询比另一个好。

正如您在问题中所观察到的，执行计划中显示的百分比并不是确定最佳查询的唯一标准。在以下示例中，我有两个查询执行相同的任务。执行计划显示两者同样好（每个50％）。现在我用SET STATISTICS IO ON执行了查询，这显示了明显的差异。

在以下示例中，查询1使用seek，而查询2在表LWManifestOrderLineItems上使用scan。当我们实际检查执行时间时，会发现查询2工作得更好。

另请阅读Paul White的When is a Seek not a Seek?

<强> QUERY

---Preparation---------------
-----------------------------
DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO

SET STATISTICS IO ON  --IO
SET STATISTICS TIME ON

--------Queries---------------
------------------------------

SELECT LW.Manifest,LW.OrderID,COUNT(DISTINCT LineItemID)
FROM LWManifestOrderLineItems LW
INNER JOIN ManifestContainers MC
    ON MC.Manifest = LW.Manifest
GROUP BY LW.Manifest,LW.OrderID
ORDER BY COUNT(DISTINCT LineItemID) DESC  

SELECT LW.Manifest,LW.OrderID,COUNT( LineItemID) LineCount
FROM LWManifestOrderLineItems LW
WHERE LW.Manifest IN (SELECT Manifest FROM ManifestContainers)
GROUP BY LW.Manifest,LW.OrderID
ORDER BY COUNT( LineItemID) DESC  

统计数据IO

执行计划

Answer 6

查询执行时间：

DECLARE @EndTime datetime
DECLARE @StartTime datetime 
SELECT @StartTime=GETDATE() 


` -- Write Your Query`

SELECT @EndTime=GETDATE()
--This will return execution time of your query
SELECT DATEDIFF(MILLISECOND,@StartTime,@EndTime) AS [Duration in millisecs] 

查询输出会像：

优化查询费用

单击SQL Management Studio

运行查询并单击查询结果的“消息”选项卡旁边的“执行计划”。你会看到像