select語句前加：
declare @d datetime
set @d=getdate()
并在select語句后加：
select [
語句執行
花費
時間
(毫秒)]=datediff(ms,@d,getdate())
這是簡易的查看執行時間的方法。
===========================================（一下內容轉自：ＣＳＤＮ）
MSSQL Server中通過查看SQL語句執行所用的時間，來衡量SQL語句的性能。
set??? statistics??? profile??? on
set??? statistics??? io??? on
set??? statistics??? time??? on
go
你執行的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平臺上強大的數據庫平臺)
還在處理一些其他事務，你得到的統計信息都可能有一點不同。
