在存儲過程中需要臨時表的情況

Question

任何人都可以解釋我們需要在存儲過程中使用臨時表的情況嗎？

Answer 1

有很多情況下，一個複雜的連接可以真正跳過優化器，並使其做非常昂貴的事情。有時候，優化器最簡單的方法是將複雜的查詢分解爲更小的部分。你會發現很多有關使用@table變量而不是#temp表的錯誤信息，因爲@table變量總是存在於內存中 - 這是一個神話，不相信它。

如果您有一個離羣值查詢將真正受益於不在基表上的不同索引，並且您不允許（或可能有害）將該索引添加到基表（例如，它可能是一個備用聚簇索引）。解決這個問題的一種方法是將數據放入一個#temp表（它可能是基表的一個有限子集，就像一個已過濾的索引一樣），在#temp表上創建備用索引，然後運行聯接對#temp表。如果過濾到#temp表中的數據將被多次使用，則尤其如此。

還有些時候您需要針對某些數據進行多次更新，但您不希望多次更新基表。您可能需要對多種其他數據執行多項操作，而這些數據無法在一個查詢中完成。將受影響的數據放入#temp表中，執行一系列計算/修改，然後更新回基表而不是n次可能更有效。如果您在此處使用針對基表的事務，則可能會延長您的用戶鎖定時間。

另一個例子是，如果您使用的是鏈接服務器，並且跨服務器的連接變得非常昂貴。相反，您可以先將遠程數據填充到本地#temp表中，然後在本地創建索引，然後在本地運行查詢。