sql 2005中的臨時表和事務

我在c＃中編寫應用程序。我在事務內使用臨時表。我的服務器是sql 2005.是否存在任何性能威脅，我在某些地方讀到應該避免在交易中使用臨時表（http://www.sql-server-performance.com/tips/temp_table_tuning_p1.aspx在2003年2月24日添加的屏幕底部的帖子）。sql 2005中的臨時表和事務

來源

2010-09-03 Darqer

你可以舉一個你正在做的需要臨時表的操作的例子嗎？我個人無法想象爲什麼你會使用它們，當你可以將內容存儲在C＃中 – 2010-09-03 08:20:23

我有一個ID列表，並希望使用此列表來篩選選擇語句的結果。我把這個列表放到臨時表中，並在WHERE部分我篩選出 – Darqer 2010-09-03 08:35:33

這就是我們所做的。傳遞一個Guid列表，將其拉入臨時表並使用存在的動態SQL語句（sp）過濾。在我們的應用程序中找不到任何性能威脅。適用於行的行列。但我們不使用交易，因爲我們只爲我們的概覽頁面採用臨時表。我們將臨時表用於分層數據的複雜過濾機制。 – Khh 2010-09-03 12:25:20

這很容易測試。

在一個查詢窗口運行以下

BEGIN TRAN 

CREATE TABLE #T1(I INT) 
INSERT INTO #T1 VALUES (1)

然後在另一個查詢窗口運行相同。你會發現沒有阻塞。

所以在這個尖端

它會阻止他人執行相同的查詢，極大地傷害了併發性和性能的要求。在效果中，這會將您的應用程序轉變爲單用戶應用程序。

似乎不真實。

來源

2010-09-03 12:10:30

我在我的應用程序中也檢查過它，似乎同時適用於許多用戶 – Darqer 2010-09-03 19:21:51

答案在第一行：「一般來說，如果可能，應該避免臨時表。」看看你的應用程序是否足夠快。儘量避免僅基於臨時表的設計。臨時表的使用應該是應用程序中的異常而非規則。嘗試在不增加成本的情況下尋找替代設計（花在構建新設計上的時間）。
看看這篇文章，看看性能如何受到數據量的影響： http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx

來源

2010-09-03 08:30:28 dragos55

在合理努力下無法避免 – Darqer 2010-09-03 10:34:20

對於在2005年創建的db（不是兼容模式）的SQL 2005，我沒有看到阻塞的任何原因。這篇文章是針對2000年的。架構已經改變了，僅僅因爲你使用了臨時表，性能不會很差。我正在使用（而不是濫用）並且性能很好（服務器有超過50個數據庫）。 – dragos55 2010-09-03 19:50:18

sql 2005中的臨時表和事務

回答

相關問題