SQL Server中的臨時表和表變量

在SQL Server的性能調優中,有一個不可比擬的問題:那就是如何在一段需要長時間的代碼或被頻繁調用的代碼中處理臨時數據集?表變量和臨時表是兩種選擇。

  在SQL Server的性能調優中,有一個不可比擬的問題:那就是如何在一段需要長時間的代碼或被頻繁調用的代碼中處理臨時數據集?表變量和臨時表是兩種選擇。記得在給一家國內首屈一指的海運公司作SQL Server應用性能評估和調優的時候就看到過大量的臨時數據集處理需求,而他們的開發人員就無法確定什麼時候用臨時表,什麼時候用表變量,因此他們就簡單的使用了臨時表。實際上臨時表和表變量都有特定的適用環境。

  先賣弄一些基礎的知識:

  表變量

  變量都以@或@@爲前綴,表變量是變量的一種,另外一種變量被稱爲標量(可以理解爲標準變量,就是標準數據類型的變量,例如整型int或者日期型DateTime)。以@前綴的表變量是本地的,因此只有在當前用戶會話中纔可以訪問,而@@前綴的表變量是全局的,通常都是系統變量,比如說@@error代表最近的一個T-SQL語句的報錯號。當然因爲表變量首先是個變量,因此它只能在一個Batch中生存,也就是我們所說的邊界,超出了這個邊界,表變量也就消亡了。

  表變量存放在內存中,正是因爲這一點所有用戶訪問表變量的時候SQL Server是不需要生成日誌。同時變量是不需要考慮其他會話訪問的問題,因此也不需要鎖機制,對於非常繁忙的系統來說,避免鎖的使用可以減少一部分系統負載。

  表變量另外還有一個限制就是不能創建索引,當然也不存在統計數據的問題,因此在用戶訪問表變量的時候也就不存在執行計劃選擇的問題了(也就是以爲着編譯階段後就沒有優化階段了),這一特性有的時候是件好事,而有些時候卻會造成一些麻煩。

  臨時表

  臨時對象都以#或##爲前綴,臨時表是臨時對象的一種,還有例如臨時存儲過程、臨時函數之類的臨時對象,臨時對象都存儲在tempdb中。以#前綴的臨時表爲本地的,因此只有在當前用戶會話中纔可以訪問,而##前綴的臨時表是全局的,因此所有用戶會話都可以訪問。臨時表以會話爲邊界,只要創建臨時表的會話沒有結束,臨時表就會持續存在,當然用戶在會話中可以通過DROP TABLE命令提前銷燬臨時表。

  我們前面說過臨時表存儲在tempdb中,因此臨時表的訪問是有可能造成物理IO的,當然在修改時也需要生成日誌來確保一致性,同時鎖機制也是不可缺少的。

  跟表變量另外一個顯著去別就是臨時表可以創建索引,也可以定義統計數據,因此SQL Server在處理訪問臨時表的語句時需要考慮執行計劃優化的問題。

  表變量 vs. 臨時表

  表變量 臨時表
數據集的存儲位置 內存(不考慮被換到頁面文件這種情況) 磁盤(不考慮訪問後被緩存到內存中)
是否需要日誌
是否可以創建索引
是否可以使用統計數據
是否可以在多會話中訪問
是否需要鎖機制

  結論

  綜上所述,大家會發現臨時表和表變量在底層處理機制上是有很多差別的。

  簡單地總結,我們對於較小的臨時計算用數據集推薦使用表變量。如果數據集比較大,如果在代碼中用於臨時計算,同時這種臨時使用永遠都是簡單的全數據集掃描而不需要考慮什麼優化,比如說沒有分組或分組很少的聚合(比如說COUNT、SUM、AVERAGE、MAX等),也可以考慮使用表變量。使用表變量另外一個考慮因素是應用環境的內存壓力,如果代碼的運行實例很多,就要特別注意內存變量對內存的消耗。

  一般對於大的數據集我們推薦使用臨時表,同時創建索引,或者通過SQL Server的統計數據(Statisitcs)自動創建和維護功能來提供訪問SQL語句的優化。如果需要在多個用戶會話間交換數據,當然臨時表就是唯一的選擇了。需要提及的是,由於臨時表存放在tempdb中,因此要注意tempdb的調優。

再議SQL Server臨時表和表變量

 今天在我和一家軟件公司的開發人員討論數據庫設計調優的時候又討論到了表變量和臨時表的問題,覺得這個問題確實是一個爭議比較大的問題。

  其實從上次發表了表變量和臨時表的一個帖子http://database.ctocio.com.cn/tips/442/8206442.shtml以來,也有些人留言,也有些人發過郵件討論這個問題。其實表變量和臨時表的區別雖然有一些,但是兩者最根本的區別還是在於

  對存儲的需求:表變量和臨時表都消耗Tempdb中的存儲空間,但是進行數據更新的時候,表變量不會寫日誌,而臨時表則會寫日誌。(這一點是經過腳本測試的,表變量並不像我們想象的那樣,只寫在內存而不出現在Tempdb中。)

  對優化的支持:表變量不支持索引和統計數據,臨時表則可以支持索引和統計數據。

  通常需要表變量或者臨時表的情況都是一些需要支持臨時計算結果集的地方,那麼就有一些常見的情況了:

  如果臨時結果集僅僅需要往裏面寫數據,比如通過一個循環多次查找相關數據併合成一個臨時結果集,那麼就可以使用表變量。(結果有人提到了返回結果集的時候需要有排序,但是表變量不支持索引阿。其實這個不要緊,因爲表變量雖然不支持索引,但是表變量支持主鍵阿,所以可以利用主鍵來替代索引。)

  如果臨時結果集不太多需要更改,而是更多地充當一個臨時的關聯數據集去參加各種數據集的連接(JOIN),那麼索引和統計數據可能會更加適合一些(當然這個臨時結果集要足夠大,這樣索引和統計數據帶來的代價纔可以被彌補掉)。

  由於表變量不支持統計數據,因此在一個存儲過程中使用表變量可以減少由於數據變化而導致的重新編譯問題。

  當然,除了索引和統計數據這個明顯的限制外,表變量同時也不支持並行執行計劃,因此對於大型的臨時結果集,表變量也不是一個好的選擇。

  前面一個關於表變量和臨時表的貼子,有一位robi_xu的朋友提到的問題也確實是在選擇表變量和臨時表時候的一些問題。

  對於函數中不能支持臨時表是由於函數不能對函數作用域外部的資源狀態造成永久性的更改,在SQLServer中也稱爲副作用(sideeffect)。不過如果在函數中使用大型的臨時結果集是不推薦的,因爲如果將這樣的函數放置到一個查詢中會造成很明顯的性能問題,因此這種情況一般都採用存儲過程之類的批處理腳本。

  對於動態腳本不支持表變量的原因是因爲存儲過程不接受表類型的參數。不過如果表變量的聲明和賦值都在sp_executesql的參數中的話,sp_executesql就可以執行了,因爲這個時候表變量就存在sp_executesql的stmt參數裏面,不需要傳入,例如下面的代碼:(當然這樣的實用性也就沒有多少了)

  DECLARE @m nvarchar(max)

  SET @m = N"DECLARE @t TABLE (ID int);INSERT INTO @tVALUES(1);SELECT * FROM @t T"

  EXEC sp_executesql @m

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章