1

我有一個相對複雜的查詢,有幾個自連接,它可以在一個相當大的表上工作。 爲了使查詢更快地執行,我只需要使用數據的一個子集。 根據傳遞的參數,數據的所述子集可以在12000和120000行之間。SQL Server多語句UDF - 臨時存儲數據的方式

更多細節可以在這裏找到:SQL Server CTE referred in self joins slow

正如你所看到的,我使用的是CTE之前返回數據子集,這引起了一些性能問題與SQL Server進行重新運行在Select語句CTE用於每個連接,而不是僅僅運行一次並重用其數據集。

使用臨時表的替代方法工作得更快(同時在UDF主體之外的單獨窗口中測試查詢)。 但是,當我試圖在多語句UDF中實現此功能時,SQL Server強烈提醒我說,由於某種原因,多語句UDF不支持臨時表...但是,UDF確實允許表變量,但由於某些原因,UDF不支持臨時表。所以我嘗試過,但是性能是非常糟糕的,因爲我的查詢需要1m40才能完成,而CTE版本只有需要40秒。 我相信,表變量是在這個線程上市速度慢的原因:Table variable poor performance on insert in SQL Server Stored Procedure

臨時表的版本需要大約1秒,但我不能讓它成爲一個函數由於SQL Server的限制,我將表返回給調用者。

考慮到CTE和表變量都太慢了,臨時表在UDF中被拒絕了,我的選項是爲了讓我的UDF能夠快速執行?

非常感謝。

+0

問題與表變量是查詢優化器的作用,雖然他們總是會返回一個行,因此會導致一些錯誤的決定。如果你知道的更好,你可以強制一個更好的計劃。你在什麼版本的SQL Server? 2005年還是2008年? – 2010-06-16 18:16:41

+0

SQL Server 2005,謝謝。 – 2010-06-16 18:21:47

回答

3

在很多這樣的情況下,我們所需要做的就是爲這些表變量聲明主鍵,並且速度又很快。

+0

非常感謝:你救了我,它已經解決了我的問題,現在只需要幾秒鐘的時間 任何想法爲什麼臨時表不需要這樣做,而且大部分時間更快? – 2010-06-17 21:22:19

0

一個kludgey變通我已經用涉及代碼如下所示(僞代碼如下):

CREATE TEMP TABLE #foo 

EXECUTE MyStoredProcedure 

SELECT * 
from #foo 

GO 

-- Stored procedure definition 
CREATE PROCEDURE MyStoredProcedure 
AS 

INSERT #foo values (whatever) 

RETURN 
GO 

總之,存儲過程中的引用,並使用通過調用過程中創建一個臨時表(或常規)。這會起作用,但如果你沒有清楚地記錄下來,可能會讓其他人感到困惑,並且你會得到重新編譯,統計信息重新編譯以及其他可能會消耗不需要的時鐘週期的奇怪現象。

+0

謝謝,我剛剛嘗試過這樣的事情......通過使我的UDF進入存儲過程,然後創建另一個UDF並執行類似於 INSERT INTO @variableTable EXEC mySp(@Param1,@ Param2, @ Param3) 爲了從UDF獲取表格......但問題在於INSERT EXEC在函數內部是不允許的。 錯誤=「在函數中無效使用副作用運算符'INSERT EXEC'。「 – 2010-06-16 18:38:37

+0

查看@ KM的建議,他們可能會很難正確實施,但它可能會做你想做的事情 – 2010-06-16 19:23:56

相關問題