sql查詢性能調試，用SET STATISTICS IO和SET STATISTICS TIME---解釋比較詳細

        一個查詢須要的CPU、IO資源越多，查詢運行的速度就越慢，所以，描述查詢性能調節任務的另外一種方式是，應該以一種使用更少的CPU、IO資源的方式重寫查詢命令，若是可以以這樣一種方式完成查詢，查詢的性能就會有所提升。

        若是調節查詢性能的目的是讓它使用盡量少的服務器資源，而不是查詢運行的時間最短，那麼就更容易測試你採起的措施是提升了查詢的性能仍是下降了查詢的性能。尤爲是在資源利用不斷變化的服務器上更是如此。首先，須要搞清楚在對查詢進行調節時，如何測試咱們的服務器的資源使用狀況。
        在開始咱們的例子前，先運行下面的這二條命令（不要在正在使用的服務器上執行），這二條命令將清除SQL Server的數據和過程緩衝區，這樣可以使咱們在每次執行查詢時在同一個起點上，不然，每次執行查詢獲得的結果就不具備可比性了：
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
輸入並運行下面的Transact-SQL命令：
SET STATISTICS IO ON  
SET STATISTICS TIME ON
一旦上面的準備工做完成後，運行下面的查詢：
SELECT * FROM [order details]

顯示結果：

SQL Server parse and compile time: （SQL Server解析和編譯時間：） CPU time = 10 ms, elapsed time = 61 ms. ……（1） SQL Server parse and compile time: （SQL Server解析和編譯時間：） CPU time = 0 ms, elapsed time = 0 ms. ……（2） （所影響的行數爲 2155 行） ……（3） Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9. （表：Order Details，掃描計數1，邏輯讀取10 次，物理讀取1 次，預讀9次） ……（4） SQL Server Execution Times: （SQL Server執行時間：） CPU time = 30 ms, elapsed time = 387 ms. ……（5）

標誌（1）表示SQL Server解析「ELECT * FROM [order details]」命令並將解析的結果放到SQL Server的過程緩衝區中供SQL Server使用所須要的CPU運行時間和總的時間。
標誌（2）表示SQL Server從過程緩衝區中取出解析結果供執行的時間，大多數狀況下這二個值都會是0，由於這個過程執行得至關地快。
標誌（5）表示執行此次查詢使用了多少CPU運行時間和運行查詢使用了多少時間。CPU運行時間是對運行查詢所須要的CPU資源的一種相對穩定的測量方法，與CPU的忙閒程度沒有關係。可是，每次運行查詢時這一數字也會有所不一樣，只是變化的範圍沒有總時間變化大。總時間是對查詢執行所須要的時間（不計算阻塞或讀數據的時間），因爲服務器上的負載是在不斷變化的，所以這一數據的變化範圍有時會至關地大。（因爲CPU佔用時間是相對穩定的，所以可使用這一數據做爲衡量你的調節措施是提升了查詢性能仍是下降了查詢的性能的一種方法。）
標誌（4）是SET STATISTICS IO的效果

Scan Count：在查詢中涉及到的表被訪問的次數。在咱們的例子中，其中的表只被訪問了1次，因爲查詢中不包括鏈接命令，這一信息並非十分有用，但若是查詢中包含有一個或多個鏈接，則這一信息是十分有用的。（一個循環外部的表的Scan Count值爲1，但對於一個循環內的表而言，其值爲循環的次數。能夠想象獲得，對於一個循環內的表而言，其ScanCount值越小，它所使用的資源越少，查詢的性能也就越高。所以在調節一個帶鏈接的查詢的性能時，須要關注Scan Count的值，在進行調節時，注意觀察它是增長仍是減小了。）

Logical Reads: 這是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的數據。咱們知道，SQL Server在能夠對任何數據進行操做前，必須首先把數據讀取到其數據緩衝區中。此外，咱們也知道SQL Server什麼時候會從數據緩衝區中讀取數據，並把數據讀取到大小爲8K字節的頁中。那麼LogicalReads的意義是什麼呢？Logical Reads是指SQL Server爲獲得查詢中的結果而必須從數據緩衝區讀取的頁數。在執行查詢時，SQL Server不會讀取比實際需求多或少的數據，所以，當在相同的數據集上執行同一個查詢，獲得的LogicalReads的數字老是相同的。（SQL Server執行查詢時的Logical Reads值每一次這個數值是不會變化的。所以，在進行查詢性能的調節時，這是一個能夠用來衡量你的調節措施是否成功的一個很好的標準。若是Logical Reads值降低，就代表查詢使用的服務器資源減小，查詢的性能有所提升。若是Logical Reads值增長，則表示調節措施下降了查詢的性能。在其餘條件不變的狀況下，一個查詢使用的邏輯讀越少，其效率就越高，查詢的速度就越快。）

Physical Reads：物理讀，在執行真正的查詢操做前，SQL Server必須從磁盤上向數據緩衝區中讀取它所須要的數據。在SQL Server開始執行查詢前，它要做的第一件事就是檢查它所須要的數據是否在數據緩衝區中，若是在，就從中讀取，若是不在，SQLServer必須首先將它須要的數據從磁盤上讀到數據緩衝區中。咱們能夠想象獲得，SQL Server在執行物理讀時比執行邏輯讀須要更多的服務器資源。所以，在理想狀況下，咱們應當儘可能避免物理讀操做。下面的這一部分聽起來讓人容易感到糊塗了。在對查詢的性能進行調節時，能夠忽略物理讀而只專一於邏輯讀。你必定會納悶兒，剛纔不是還說物理讀比邏輯讀須要更多的服務器資源嗎？狀況確實是這樣， SQLServer在執行查詢時所須要的物理讀次數不可能經過性能調節而減小的。減小物理讀的次數是DBA的一項重要工做，但它涉及到整個服務器性能的調節，而不只僅是查詢性能的調節。在進行查詢性能調節時，咱們不能控制數據緩衝區的大小或服務器的忙碌程度以及完成查詢所須要的數據是在數據緩衝區中仍是在磁盤上，惟一咱們可以控制的數據是獲得查詢結果所須要執行的邏輯讀的次數。所以，在查詢性能的調節中，咱們能夠問心無愧地不理會SET STATISTICS IO命令提供的PhysicalRead的值。（減小物理讀次數、加快SQL Server運行速度的一種方式是確保服務器的物理內存足夠多。）

Read-Ahead Reads： 與Physical Reads同樣，這個值在查詢性能調節中也沒有什麼用。Read-Ahead Reads表示SQL Server在執行預讀機制時讀取的物理頁。爲了優化其性能，SQL Server在認爲它須要數據以前預先讀取一部分數據，根據SQLServer對數據需求預測的準確程度，預讀的數據頁可能有用，也可能沒用。在本例中，Read-Ahead Reads的值爲9，Physical Read的值爲1，而LogicalReads的值爲10，它們之間存在着簡單的相加關係。                    那麼我在服務器上執行查詢時的過程是怎麼樣的呢？首先，SQL Server會開始檢查完成查詢所須要的數據是否在數據緩衝區中，它會很快地發現這些數據不在數據緩衝區中，並啓動預讀機制將它所須要的10個數據頁中的前9個讀取到數據緩衝區。當SQL Server檢查是否所須要的所有數據都已經在數據緩衝區時，會發現已經有9個數據頁在數據緩衝區中，還有一個不在，它就會當即再次讀取磁盤，將所須要的頁讀到數據緩衝區。一旦全部的數據都在數據緩衝區後，SQLServer就能夠處理查詢了。

 

總結：在對查詢的性能進行調節時用一些科學的標準來測量你的調節措施是否有效是十分重要的。問題是，SQL Servers的負載是動態變化的，使用查詢總的運行時間來衡量你正在調節性能的查詢的性能是提升了仍是沒有，並非一個合理的方法。 更好的方法是比較多個數據，例如邏輯讀的次數或者查詢所使用的CPU時間。所以在對查詢的性能進行調節時，須要首先使用SET STATISTICS IO和SET STATISTICS TIME命令向你提供一些必要的數據，以便肯定你對查詢性能進行調節的措施是否真正地獲得了目的。

======================
1.測試前用二條命令清除SQL Server的數據和過程緩衝區，以保證測試條件相同：
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
2.SET STATISTICS TIME：看cpu時間   
3.SET STATISTICS IO：關注scan count（計數)------查詢讀取的表數量；logical read( 邏輯讀)次數
======================