Mat*_*lie 50 sql sql-server optimization sql-server-2005 sql-execution-plan
我正在尝试确定两个不同查询的相对性能,并且有两种方法可以测量这个:
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的集合,所以我想我有几个问题:
有没有明确的来源来解释这项措施的含义？
人们使用什么其他"查询性能"指标,它们的相对优点是什么？
值得注意的是,这是一个中型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以及更多的读取需要更少的时间:)
gbn*_*gbn 36
探查器跟踪将其置于透视中.
查询B使用并行性:CPU>持续时间,例如查询使用2个CPU,每个平均1.15秒
查询A可能不是:CPU <持续时间
这解释了相对于批处理的成本:17%的更简单的非并行查询计划.
优化器确定查询B更昂贵并且将从并行性中受益,即使这需要额外的努力.
但请记住,查询B使用100%的2 CPUS(因此4个CPU为50%)大约一秒左右.查询A使用100%的单个CPU 1.5秒.
查询A的峰值较低,但代价是持续时间增加.有一个用户,谁在乎？有了100,也许它会有所不同......
小智 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.