对于语句的运行,除了执行计划本身,还有一些其他因素要考虑,例如语句的编译时间、执行时间、做了多少次磁盘读等。
如果DBA能够把问题语句单独测试运行,可以在运行前打开下面这三个开关,收集语句运行的统计信息。 
这些信息对分析问题很有价值。 
复制代码 代码如下:
 
SET STATISTICS TIME ON 
SET STATISTICS IO ON 
SET STATISTICS PROFILE ON 
 SET STATISTICS TIME ON 
-------------------------------------------------------------------------------- 
请先来看看SET STATISTICS TIME ON会返回什么信息。先运行语句: 
复制代码 代码如下:
 
DBCC DROPCLEANBUFFERS 
--清除buffer pool里的所有缓存数据 
DBCC freeproccache 
GO 
--清除buffer pool里的所有缓存的执行计划 
SET STATISTICS TIME ON 
GO 
USE [AdventureWorks] 
GO 
SELECT DISTINCT([ProductID]),[UnitPrice] FROM [dbo].[SalesOrderDetail_test] 
WHERE [ProductID]=777 
GO 
SET STATISTICS TIME OFF 
GO 
 除了结果集之外,SQLSERVER还会返回下面这两段信息 
复制代码 代码如下:
 
SQL Server 分析和编译时间: 
CPU 时间 = 15 毫秒,占用时间 = 104 毫秒。 
SQL Server 分析和编译时间: 
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 
(4 行受影响) 
SQL Server 执行时间: 
CPU 时间 = 171 毫秒,占用时间 = 1903 毫秒。 
SQL Server 分析和编译时间: 
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 
 大家知道SQLSERVER执行语句是分以下阶段:分析-》编译-》执行 
根据表格的统计信息分析出比较合适的执行计划,然后编译语句,最后执行语句
下面说一下上面的输出是什么意思: 
-------------------------------------------------------------------------------- 
1、CPU时间 :这个值的含义指的是在这一步,SQLSERVER所花的纯CPU时间是多少。也就是说,语句花了多少CPU资源 
2、占用时间 :此值指这一步一共用了多少时间。也就是说,这是语句运行的时间长短,有些动作会发生I/O操作,产生了I/O等待,或者是遇到阻塞、产生了阻塞等待。总之时间用掉了,但是没有用CPU资源。所以占用时间比CPU时间长是很正常的 ,但是CPU时间是语句在所有CPU上的时间总和。如果语句使用了多颗CPU,而其他等待几乎没有,那么CPU时间大于占用时间也是正常的 
3、分析和编译时间:这一步,就是语句的编译时间。由于语句运行之前清空了所有执行计划,SQLSERVER必须要对他编译。 
这里的编译时间就不为0了。由于编译主要是CPU的运算,所以一般CPU时间和占用时间是差不多的。如果这里相差比较大,就有必要看看SQLSERVER在系统资源上有没有瓶颈了。 
这里他们是一个15毫秒,一个是104毫秒 
4、SQLSERVER执行时间: 语句真正运行的时间。由于语句是第一次运行,SQLSERVER需要把数据从磁盘读到内存里,这里语句的运行发生了比较长的I/O等待。所以这里的CPU时间和占用时间差别就很大了,一个是171毫秒,而另一个是1903毫秒 
总的来讲,这条语句花了104+1903+186=2193毫秒,其中CPU时间为15+171=186毫秒。语句的主要时间应该是都花在了I/O等待上 
现在再做一遍语句,但是不清除任何缓存 
复制代码 代码如下:
 
SET STATISTICS TIME ON 
GO 
SELECT DISTINCT([ProductID]),[UnitPrice] FROM [dbo].[SalesOrderDetail_test] 
WHERE [ProductID]=777 
GO 
SET STATISTICS TIME OFF 
GO 
 这次比上次快很多。输出时间统计信息是: 
复制代码 代码如下:
 
SQL Server 分析和编译时间: 
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 
SQL Server 分析和编译时间: 
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 
(4 行受影响) 
SQL Server 执行时间: 
CPU 时间 = 156 毫秒,占用时间 = 169 毫秒。 
SQL Server 分析和编译时间: 
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 
 由于执行计划被重用,“SQL分析和编译时间” CPU时间是0,占用时间是0 
由于数据已经缓存在内存里,不需要从磁盘上读取,SQL执行时间 CPU时间是156,占用时间这次和CPU时间非常接近,是169。
这里省下运行时间1903-169=1734毫秒,从这里可以再次看出,缓存对语句执行性能起着至关重要的作用 
为了不影响其他测试,请运行下面的语句关闭SET STATISTICS TIME ON 
复制代码 代码如下:
 
SET STATISTICS TIME OFF 
GO 
 SET STATISTICS IO ON 
-------------------------------------------------------------------------------- 
这个开关能够输出语句做的物理读和逻辑读的数目。对分析语句的复杂度有很重要的作用 
还是以刚才那个查询作为例子 
复制代码 代码如下: