1.前言   

     對於優化SQL語句或儲存過程，以前主要是用如下語句來判斷具體執行時間，但是SQL環境是複雜多變的，下面語句並不能精準判斷效能是否提高；如果需要精確知道CPU、IO等資訊，就無能為力了。

PRINT convert(varchar(30),getdate(),121)

select * from Sales.SalesOrderDetail where SalesOrderID > 64185

PRINT convert(varchar(30),getdate(),121)

　　這時候如果使用SET STATISTICS TIME ON

　　DBCC DROPCLEANBUFFERS 清除緩衝區

　　DBCC FREEPROCCACHE 刪除計劃快取記憶體中的元素

2.測試

     2.1 首先執行下面指令碼

--開啟統計資訊

SET STATISTICS TIME ON

SET STATISTICS IO ON

GO

 

select * from Sales.SalesOrderDetail where SalesOrderID > 64185
 


GO

結果如下

--1.

SQL Server 分析和編譯時間: 

   CPU 時間 = 0 毫秒，佔用時間 = 53 毫秒。

--2.

SQL Server 分析和編譯時間: 

   CPU 時間 = 0 毫秒，佔用時間 = 0 毫秒。

 

(35292 行受影響)

--3.

表 'SalesOrderDetail'。掃描計數 1，邏輯讀取 337 次，物理讀取 4 次，預讀 333 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。

 

--4.

 SQL Server 執行時間:

   CPU 時間 
 
= 47 毫秒，佔用時間 = 893 毫秒。

　　說明：

      標記1：表示將語句的結果放到SQL緩衝區所需要的CPU時間和總時間

      標記2：標識從緩衝區中取出解析結果所需要的時間

      標記4：標識這次查詢使用了多少CPU時間和總的時間，其中CPU時間是對查詢所需CPU資源的一種比較穩定的測量方式；總時間則跟SQL伺服器有關，因此比較不穩定；所以效能判斷的時候可以以CPU時間來做標準。

      標記3：資源時間；其中邏輯讀是指SQL從緩衝區讀取的資料；物理讀是指從資料從磁碟讀取到緩衝區中；

      2.2 再次執行查詢語句結果如下，由於第一次執行的時候，資料已經從磁碟讀取到緩衝區，因此標記1的時間也就是0了，標記3物理讀也為0了。

--1.

SQL Server 分析和編譯時間: 

   CPU 時間 = 0 毫秒，佔用時間 = 0 毫秒。

--2.

SQL Server 分析和編譯時間: 

   CPU 時間 = 0 毫秒，佔用時間 = 0 毫秒。

 

(35292 行受影響)

--3.

表 'SalesOrderDetail'。掃描計數 1，邏輯讀取 337 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。

 

--4.

 SQL Server 執行時間:

   CPU 時間 = 32 毫秒，佔用時間 = 848 毫秒。

     2.3 在優化SQL語句的時候可以從CPU時間，邏輯讀取數來判斷效能是否提升，而且這2個指標是比較真實的反映了SQL執行情況的。這裡只是簡單介紹了一下這2個命令的一些基本資訊，則需更加深入瞭解SQL底層知識。