如何測試sql語句執行時間
在MSSQL Server中通過查看SQL語句執行所用的時間，來衡量SQL語句的性能。
set statistics profile on set statistics io on set statistics time on 你執行的SQL語句 go set statistics profile off set statistics io off set statistics time off
執行完后點消息即可。
補充說明：
set statistics io檢查查詢所產生的讀和寫
set statistics time檢查查詢的運行時間
當運行一sql語句，在消息中會顯示如：
SQL Server分析和編譯時間：CPU時間=0毫秒，占用時間=10毫秒。SQL Server分析和編譯時間：CPU時間=0毫秒，占用時間=1毫秒。
(0行受影響)表't_login_session'。掃描計數1，邏輯讀取2次，物理讀取0次，預讀0次，lob邏輯讀取0次，lob物理讀取0次，lob預讀0次。
(3行受影響)
SQL Server執行時間：CPU時間=0毫秒，占用時間=11毫秒。SQL Server分析和編譯時間：CPU時間=0毫秒，占用時間=1毫秒。
SQL Server執行時間：CPU時間=0毫秒，占用時間=1毫秒。
SQL Server執行時間：CPU時間=0毫秒，占用時間=1毫秒。
表't_login_session'。掃描計數1，邏輯讀取2次，物理讀取0次，預讀0次，lob邏輯讀取0次，lob物理讀取0次，lob預讀0次。
這個掃描統計告訴我們掃描執行的數量，邏輯讀顯示的是從緩存中讀出來的頁面的數量，物理讀顯示的是從磁盤中讀的頁面的數量，預讀顯示了放置在緩存中用於將來讀操作的頁面數量。
通過看這些信息我們能得到些什么呢?
◆這個查詢沒有掃描整個表，在表中的數據量超過1.5M字節，而僅僅執行了53個邏輯I/O操作就得到了結果。這表明該查詢發現了一個可用來計算結果的索引，並且掃描索引比掃描所有數據頁花費更少的I/O操作。
◆索引頁幾乎全部放在數據緩存中，所以物理讀的值是零。這是因為我們之前不久是在employees表上執行了其他查詢，此時表和它的索引已經被緩存。你的查詢開銷可能有不同。
◆Microsoft 報告沒有read-ahead(預讀)活動。在這種情況下，數據和索引頁已經被緩存起來了。當對一個很大的表作表掃描時，read-ahead可能會半路 插入進來，並且在你的查詢用到它們之前緩存起所需的頁。當sql server(WINDOWS平台上強大的數據庫平台)確定你的事務是順序讀取數據庫頁並且認為它能預測到你下一步將用到的頁面時，Real-ahead 會自動打開。實際上一個獨立的sql server(WINDOWS平台上強大的數據庫平台)連接在你的進程之前已開始運行並為它緩存數據頁。(配置和優化read-ahead參數已超出這篇 文章的討論范圍。
在這個例子中，該查詢已經盡可能有效率地執行了，不必進一步優化。
SQL Server分析和編譯時間：CPU時間=0毫秒，占用時間=10毫秒。
sql server(WINDOWS平台上強大的數據庫平台)僅僅花費10毫秒時間去分析和編譯該查詢。花費0毫秒去執行它(在查詢結果可看到)。其真實的意思 是這個查詢所花費的時間太短以至不能計量。最后的信息報告了這個SET STATISTICS TIME OFF命令相關的分析及編譯花費了1毫秒。你可以忽略這個信息。
SQL Server執行時間：CPU時間=0毫秒，占用時間=1毫秒。
是我們關注的運行時間
注 意實耗時間和CPU時間是以毫秒顯示。這個數字在你的電腦上可能會改變(但是不要嘗試與我們的筆記本電腦比較你機器的性能，因為這不是代表性的指標)。而 且，每次你執行這個腳本，考慮到你的sql server(WINDOWS平台上強大的數據庫平台)還在處理一些其他事務，你得到的統計信息都可能有一點不同。
2.簡易得出SQL語句的執行時間的方法
select語句前加：declare @d datetime set @d=getdate()並在select語句后加：select[語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())
----------------------------
我 做優化的時候關注3個：CPU、邏輯讀和邏輯寫。CPU主要是編譯和重編譯，而邏輯寫主要出在insert的時候臨時表查出來的數據量太大，建議縮減不必 要的部分，舉個例子，insert into #temp select id ,name from xxx表，而這個只是中間結果，只有在最終展示的時候才需要展示name，這次你就不應該把name字段insert進去。
然后就是邏輯讀，如果 內存足夠，那么幾乎不引起物理讀（除非維護所需，比如Checkpoint、lazy Writer等），聯機叢書上說，就算是寫操作很頻繁的系統，其讀操作一般都還是比寫操作高5~10倍，所以往往性能優化的書籍名字都是查詢優化，而不是 更改優化等等的名字。邏輯讀主要在內存發生。努力降低邏輯讀，查詢的速度會有明顯提升，其實我覺得邏輯讀還是會有很高成本，每一次讀（SQLServer 按頁來讀），都要8K的空間，內存足夠的時候，就是8K內存，內存不夠，就是8K物理讀，也就是硬盤空間，邏輯讀越高，搜索的內存面積越廣。降低邏輯讀的 主要手段我個人認為有兩個：
1、改寫寫法，把不必要的部分不查出來或者真正需要的時候才查出來。
2、調整索引，索引合理，你需要搜索的頁面就少。這也是為什么有索引的查詢會很快，很多查詢光調整索引和where的順序，就能從小時降到秒級別。