代码之家 › 专栏 › 技术社区 › MatBailie

衡量查询性能:“执行计划查询成本”与“耗时”

sql-execution-plan optimization sql-server-2005 sql-server sql

MatBailie · 技术社区 · 17 年前

我试图确定两个不同查询的相对性能,并有两种方法可以衡量这一点:

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%

是否有明确的来源来解释这一措施的含义?

值得注意的是,这是一个中等大小的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

6 回复 | 直到 14 年前

gbn 17 年前

分析器跟踪使其更具洞察力。

查询A:1.3秒CPU,1.4秒持续时间
查询B:2.3秒CPU,1.2秒持续时间

查询B正在使用并行性:CPU>持续时间例如,查询使用2个CPU,平均每个CPU 1.15秒

查询A可能不是:CPU<持续时间

这就解释了相对于批处理的成本:对于更简单、非并行的查询计划,成本为17%。

优化器计算出查询B更昂贵,并且将从并行性中受益,即使这样做需要额外的努力。

不过请记住,查询B在一秒钟左右的时间里使用了2个CPU的100%(因此4个CPU为50%)。查询A在1.5秒内使用了单个CPU的100%。

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

Jason Plank Maksim Kondratyuk 14 年前

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.

Quassnoi 17 年前

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

Query cost 优化器认为查询需要多长时间(相对于总批处理时间)。

优化器试图通过查看您的查询和数据统计数据、尝试几个执行计划并选择成本最低的计划来选择最佳查询计划。

Here 你可以阅读更多关于它如何做到这一点的详细信息。

正如你所看到的,这可能与你实际得到的结果有很大不同。

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

Jason Plank Maksim Kondratyuk 14 年前

使用 SET STATISTICS TIME ON

在你的询问之上。

在结果选项卡下方,您可以看到一个消息选项卡。在那里您可以看到时间。

Aki Mohammad Atiour Islam 12 年前

查询执行时间:

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]

查询输出如下:

enter image description here

要优化查询成本,请执行以下操作:

点击您的SQL管理工作室

enter image description here

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

enter image description here

LCJ 10 年前

我明白这是一个老问题,但我想添加一个例子,说明成本相同,但一个查询比另一个查询更好。

正如您在问题中所观察到的,执行计划中显示的百分比并不是确定最佳查询的唯一标准。在下面的示例中,我有两个查询执行相同的任务。执行计划显示两者都同样好(各50%)。现在,我使用以下命令执行查询 SET STATISTICS IO ON 这显示出明显的差异。

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

另请阅读 When is a Seek not a Seek? 保罗·怀特

查询

---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

执行计划