SQL Server 2000优化SELECT语句方法(2)

SET STATISTICS TIME

一个事务的实耗时间是一个不稳定的测量，因为这些时间与在服务器上其他用户的活动有关。然而，相比那些对你的用户没有任何意义的数据页数字，它提供了一些实际的测量。他们关心等待查询返回的时间消耗，不关心数据的缓存和有效的read-ahead。SET STATISTICS TIME ON命令报告下面的查询的实际占用时间和CPU使用情况。执行SET STATISTICS TIME OFF禁止这个选项。

SET STATISTICS TIME ON
GO
SELECT COUNT（*） FROM titleauthers
GO
SET STATISTICS TIME OFF
GO
Results:
SQL Server Execution Times;
 Cup time=0 ms.  Elapsed time=8672 ms.
SQL Server Parse and Compile Time:
 Cpu time=10 ms

----------------
25

(1 row(s) affected)

SQL Servre Execution Times:
 Cpu time=0 ms.? Elapsed time=10 ms.
SQL Server Parse and Compile Time:
Cup time=0 ms

第一条信息报告了多少使人困惑的占用（实耗）时间，8672豪秒，这个数据与我们的脚本不相关，这显示的是之前一个命令执行以来逝去的时间。你可以忽略这条信息。SQL Server仅仅花费10毫秒时间去分析和编译该查询。花费0毫秒去执行它（在查询结果可看到）。其真实的意思是这个查询所花费的时间太短以至不能计量。最后的信息报告了这个SET STATISTICS TIME OFF命令相关的分析及编译花费了0毫秒。你可以忽略这个信息。最重要的信息以加重字体突出显示。

注意实耗时间和CPU时间是以毫秒显示。这个数字在你的电脑上可能会改变（但是不要尝试与我们的笔记本电脑比较你机器的性能，因为这不是代表性的指标）。而且，每次你执行这个脚本，考虑到你的SQL Server还在处理一些其他事务，你得到的统计信息都可能有一点不同。

如果你需要测量一系列的查询或者存储过程的实耗持续时间，更好的办法是采用程序设计的方式（如下所示）。当你运行多个命令时你不得不进行手工合计，这是因为STATISTICS TIME只报告单个查询的持续时间。想象一下，当你对一个在循环里执行成千上万次查询的脚本进行计时的情况下，将面临大量的输出和大量的手工工作。

相反，考虑下面这个脚本在事务的前后分别捕获时间并以秒的形式报告总持续时间（你也可以使用毫秒）：

DECLARE @start_time DATETIME
SELECT @start_time=GETDATE()
<any query or a script that 
you want to time, without a GO>
SELECT  ’Elapsed Time,sec’
=DATEDIFF(second, @start_time,GETDATE())
GO

如果你的脚本被GO分成几步,你不能用本地变量来保存开始时间。变量在GO命令执行后就被销毁。但你可以象这样在临时表里保存开始时间。

CREATE TABLE #save_time (start_time DATETIME NOT NULL)
INSERT #save_time VALUES ( GETDATE())
GO

 < any script that you want to time (may include GO) >
GO
SELECT ‘Elapsed Time, sec’ = 
DATEDIFF ( second, start_time, GETDATE())
FROM TABLE #save_time
DROP TABLE #save_time

GO

请注意，SQL Server’s DATETIME 数据类型存储的时间是以3毫秒为增量。使用DATETIME数据类型不可能获得比这更细的时间粒度。