T-SQL中臨時表上索引的最佳使用方法

如果您要在存儲過程中創建臨時表並希望在其上添加一個或兩個臨時表以提高對其進行的任何其他語句的性能，是最好的方法？ Sybase如是說this：T-SQL中臨時表上索引的最佳使用方法

「在創建索引時，表必須包含數據如果創建臨時表並在空表上創建索引，則Adaptive Server不會創建列統計信息，如直方圖和密度。您在創建索引後插入數據行，優化器具有不完整的統計信息。「

但最近有同事提到，如果我在不同的存儲過程，其實際使用臨時表中的一個創建臨時表和索引，然後Adaptive Server的優化器將能夠使用它們。總的來說，我並不是很喜歡包裝程序，並沒有增加價值，所以我實際上並沒有去測試這個，但我想我會把問題放在那裏，看看是否任何人有任何其他方法或建議？

來源

2008-09-10 ninesided

的一點想法：

如果臨時表是如此之大，你必須建立索引，那麼有沒有更好的辦法來解決這個問題？
您可以強制它使用索引（如果你確信該指數是訪問表的正確方法）給予的優化器提示，形式爲：
```
SELECT * 
FROM #table (index idIndex) 
WHERE id = @id 
```

如果你有興趣的一般性能技巧，我已經回答了幾個有關的其他問題在一些長度在這裏：

來源

2008-09-30 15:53:12

將數據放入臨時表後添加索引時會出現什麼問題？

您需要注意的一件事是索引對可能同時運行的其他過程實例的可見性。

我喜歡爲這些臨時表（以及索引）添加一個guid，以確保永遠不會有衝突。這種方法的另一個好處是你可以簡單地將臨時表作爲真正的表格。

此外，請確保您需要在運行存儲過程期間多次查詢這些臨時表中的數據，否則索引創建的成本將超過select的好處。

來源

2008-09-10 11:45:09

在Sybase中，如果您創建臨時表然後在一個進程中使用臨時表，則使用表中估計的100行構建select的計劃。（該計劃是在表填充之前啓動該過程時構建的。）這可能會導致臨時表被掃描，因爲它僅爲「100行」。調用另一個proc會導致Sybase爲具有實際行數的select生成計劃，這允許優化器選擇一個更好的索引來使用。我已經看到了使用這種方法的顯着改進，但在數據庫上進行測試，因爲有時沒有區別。

來源

2008-09-15 20:29:42

T-SQL中臨時表上索引的最佳使用方法

回答

相關問題