測試數據倉庫性能的最佳方法？

Question

我有一個基於Postgresql的數據倉庫。

到現在爲止，我一直在試圖在包含我的真實數據庫的一小部分的數據庫上運行查詢。一旦我以這種方式編寫查詢以使其對這個小型測試數據庫有效，我就可以在真實的數據庫上運行這些查詢。

問題是，一旦我在真實數據庫上運行查詢，真正的數據庫將耗盡內存並開始將諸如索引和臨時表之類的內容寫入磁盤。這意味着對於測試數據庫和真實數據庫來說，不同的查詢可能是最優的。這是否意味着我必須運行需要幾分鐘才能完成的查詢才能知道哪個查詢是最優的。

Answer 1

瞭解如何解釋EXPLAIN輸出，然後在運行查詢之前檢查EXPLAIN輸出是否顯示大型數據庫中選定的查詢計劃與您所期望的類似。

Answer 2

三個問題：

1）查詢有多複雜？索引和臨時表的生成表明服務器必須生成這些東西，因爲在未編制索引的列上進行復雜的操作。這有多可能？從你的報告看來，可能的答案似乎是「複雜的」

2）回報集有多大？最終結果是100行還是100萬？從你的報告中，答案可能是任何事情。我懷疑這個問題並不重要，但至少知道這一點至關重要。

3）以不同的方式重新提出問題1，即使返回的集合很小，是否有巨大的中間結果必須在小結果的基礎上編譯？再次，我懷疑這裏的答案是正在生成大型複雜的中間結果。

這意味着至少有些事情需要編制索引，並且可能需要將數據結構化，以便更接近您想要查詢的內容。

最後一個問題是，對於大多數更重要的查詢或者只有一兩個問題，這是一個普遍的問題？

編輯回覆評論：我整天在做數據倉庫查詢，其中一些需要10分鐘左右。有些需要幾個小時，我把它們推到一個後臺工作中，並分解成幾個階段，以防止一切陷入困境。這是處理非常大的數據集的本質。

我在最初的答案中的問題旨在弄清楚如果您的問題查詢將有史以來完成。有可能在不知情的情況下編寫一個查詢，產生如此多的中間數據，您可以走開，2天后回來，並且它仍在運行。所以我會重申我原來的三個問題，它們實際上是完全回答你的問題的唯一方法。

回顧：是的，有些查詢需要更長時間，這是野獸的性質。您希望的最好效果是與正在讀取的數據量成線性關係，並且如果有一億行要處理，則需要幾分鐘而不是幾秒鐘。但更重要的是，如果一個查詢在100萬行中運行時間爲4秒，但在1億行上需要>> 400秒（如一小時），那麼我詢問的那些原始問題將幫助您找出原因，以便優化這些查詢。