sql – 测量查询性能:“执行计划查询成本”vs“所用时间”

我试图确定两个不同查询的相对性能,并有两种方法来衡量这对我可用:
1.对每个查询运行both和time
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的聚合,所以我想我有几个问题:

>是否有一个明确的来源来解释这个措施是什么意思?
>人们使用什么其他“查询性能”指标,他们的相对优点是什么?

可能需要注意的是,这是一个中型SQL Server,在具有多个处理器和100个并发用户的MS Server 2003企业版上运行MS SQL Server 2005。

编辑:

在一些麻烦后,我设法获得Profiler访问该SQL Server,并可以提供额外的信息(其中支持查询成本与系统资源,而不是执行时间本身…)

Stored_Proc    CPU      Reads    Writes   Duration   

test_1a        1313     3975     93       1386
test_1b        2297     49839    93       1207

令人印象深刻的是,多花费更多的CPU与更多的读取花费更少的时间:)

最佳答案
剖析器跟踪将其转换为透视图。

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

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

查询A可能不是:CPU<持续时间 这说明了相对于批处理的成本:对于更简单的非并行查询计划,为17%。 优化器确定,查询B更加昂贵,并且将从并行性中受益,即使这样做需要额外的努力。 记住,查询B使用2个CPUS的100%(因此4个CPU的50%)大约一秒钟。查询A使用100%的单个CPU 1.5秒。 查询A的峰值较低,以延长的持续时间为代价。
有一个用户,谁在乎?用100,也许它有区别…

转载注明原文:sql – 测量查询性能:“执行计划查询成本”vs“所用时间” - 代码日志