文章源摘自，需要的童鞋可以去查看http://sqlconcept.com/2011/05/30/testing-and-comparing-sql-server-query-performance/

測試和比較SQL Server查詢性能

前陣子我跟一個開發商，誰也打不隨意的DBA在公司中的作用。

當我們談論自己的服務器中的一個表現不佳，我意識到事情並沒有增加，所以我決定問生硬的問題：

“你如何衡量你寫的查詢的性能？你用什麼工具？“

他看着我，說：“ 。好吧，以後我寫我打開任務管理器的查詢，我執行查詢，我看看，如果有CPU中的秒殺 “

然後我意識到，這是必不可少的未來福祉的系統（和公司），我們向後退了一步，瞭解業界性能調試的工具。

此開發商沒有介意，而且我必須說，這花了大約30分鐘，他高興地性能測試他的疑問。

最近我寫了一個帖子性能調優輪，其中提到的許多性能調整工具，但在這個博客中，我將集中討論pformance收集了幾個非常重要的方法，比較和標杆。

爲什麼任務管理器還不夠嗎？

讓我們開始在根：一個查詢可以以多種方式影響SQL Server的硬件。它可以影響CPU，內存，磁盤系統中，上述的組合;查詢可以影響其它的查詢，從而其可以影響硬件。

所有的這也是由體積，規模，圖案等測定。

那麼，爲什麼任務管理器還不夠嗎？由於它具有所有上述的信息非常少。

好吧，還有什麼？

開始尋找一個查詢性能的一個好方法是看在IO和CPU狀態在SSMS中。

: 設置查詢選項

......或者只是寫這樣的查詢：

^？查看代碼的TSQL

使用的AdventureWorks;
GO
SET  STATISTICS IO   ON 
SET  STATISTICS  TIME   ON
 
選擇第名，公關。ProductReviewID 
從生產。產品 p
 加入生產。ProductReview公關
 上頁的ProductID  = PR。產品編號
 
SET  STATISTICS IO   OFF 
SET  STATISTICS  TIME   OFF

這個語句將執行，也將返回信息是這樣的：

（4行（S）受影響）
表'產品'。掃描計數1，邏輯讀取8，物理讀0次，預讀0，lob邏輯讀取0次，lob物理讀取0次，lob預讀0。
表'ProductReview“。掃描計數1，邏輯讀取4，物理讀0次，預讀0，lob邏輯讀取0次，lob物理讀取0次，lob預讀0。

SQL Server執行時間：
CPU時間= 0毫秒，佔用時間= 15毫秒。

SQL Server執行時間：
CPU時間= 0毫秒，佔用時間= 0毫秒。

另一種方式來看待這個查詢是使用客戶端的統計信息。

使用客戶端的統計數據來衡量和比較查詢

另一種更全面的方式來看待一個查詢是看事件探查器 - 它提供了有關查詢和有關併發事件的信息。

爲了得到一個甚至更好的畫面，我們可以捕捉Perfmon計數器和事件探查器跟蹤和關聯他們。這種方法顯示的查詢，併發性和系統信息。

執行計劃 - 是的，它確實給性能信息，但這是更多的關於查詢的執行，不是一個完整的畫面時所發生的事情的'臨時'的信息。執行計劃是不是穩定的，當查詢優化器（QO）產生的計劃，它認爲整個一系列因素的感覺，因此對於一個查詢的執行計劃的執行可能會有所不同（例如，看一下並行的情況下 - 有可以保存爲一個查詢兩個不同的計劃 - 1採用並行，而其他沒有使用它）

此外，該執行計劃包含相對值，即運營商的成本是相對於他們的休息。這給出了一個很好的機會，在比較同一批次執行的查詢，看看是否有在執行計劃還是什麼的總成本有差異。

最後，執行計劃並沒有給什麼（這可能看上去很可笑）是執行計劃本身的發電成本。這是事實，QO的本質是產生“足夠好”的計劃是比查詢本身的執行成本較低，但在同一時間的問題可能是因爲高數生成的計劃的而已。請記住，這在生成查詢規劃是一個相當昂貴的操作。