我有一個基本查詢，它提取Record_ID +關聯的Service_Number，然後是一個LEFT JOIN以查找其他相關的Service_Code。我已經確認每個子表中都有獨特的記錄。Teradata SQL - 瞭解將查詢結果插入易變表的性能影響
解釋計劃顯示此查詢的總估計時間爲「1分25秒」，但如果我在查詢中包裝CREATE MULTISET VOLATILE TABLE語句，突然解釋計劃顯示「72小時20分鐘」。如果我仍然運行VOLATILE TABLE創建，則該作業將在一分鐘內完成。
這些額外的加載時間有什麼貢獻？有什麼我可以看看，以減少這種情況？
估計的時間並不是估計運行需要多長時間。他們應該真的把它稱爲「估計成本」，因爲它並不真正表明對實際運行時間的遠程現實估計。
沒有看到您的實際腳本，我的猜測是您選擇了一個糟糕的主要索引爲您的易失性表。由於Teradata是大規模並行的，它基於主索引在AMP之間分配數據。如果您選擇了錯誤的主索引，那麼您的數據不會均勻分佈，並且可能會嘗試將所有數據加載到單個AMP中（最差情況下）。這可能導致嚴重的緩慢。
如果您只是想快速加載數據而不必擔心下游性能，那麼爲您的表指定NO PRIMARY INDEX，它將確保所有AMP的數據均勻分佈。但是，當您試圖將其加入到其他表格時，這可能會使您在稍後表現不佳。因此，對您的主要索引進行一些思考是一個好主意。
實際上，如果您記住我們正在討論成本估算（而不是實際時間），則需要1分鐘25秒並不是一個可怕的估計。如果你已經看到一個非常快的創建時間，那麼選擇一個好的主索引可能沒有太大的區別。在大規模並行數據庫平臺中，表刪除和創建需要比其他數據庫平臺長 –
謝謝。正如我剛纔在我的原始問題的評論中所加的那樣，無論我定義的主索引是甚麼NO PRIMARY索引，都會在解釋計劃中顯示估計時間的大幅增加。這成爲一個問題，因爲在我無法提交執行查詢之前，DBA已經爲預計時間定義了最大限制 – user3867061
噢，然而可能我加入的第二張表有一個定義差的主索引，導致了歪斜？我會檢查這個 – user3867061
我猜MULTISET和缺乏主索引消除歪斜會大大增加時間 –
Multiset實際上使它更快，因爲它不必檢查重複。不過，我認爲你對主要指數是正確的。 –
有趣的是，無論我定義的主要指標如何，即使沒有主要指標，都會顯示預計時間的大幅增加。由於DBA已經定義了最大「估計時間」限制，所以這成爲一個問題，因爲Teradata不允許執行我的查詢。 – user3867061