問題性能數據庫有很多索引

Question

我們的產品同時需要測試大約350名候選人。在測試結束時，每個候選人的結果都被移至一個充滿索引的數據倉庫。對於每個測試，都會在數據倉庫中輸入大約400條記錄。所以400 x 350是很多記錄。如果數據倉庫中沒有太多記錄，一切都很順利。但是，如果數據倉庫中已經有很多記錄，那麼很多插入失敗...

有沒有辦法讓索引只在一天結束時重建或者不是真正的問題？或者你會如何解決這個問題？

Answer 1

我已經使用了normalized和Kimball星型數據倉庫，這聽起來不像是應該遇到的問題。即使在小型數據倉庫中，我也會說140000行不是很多行。

爲什麼插入失敗？通常在Kimball風格的倉庫中，沒有任何插入操作失敗 - 例如在事實表中，插入操作始終有一組唯一與尺寸和顆粒相關的主鍵（如日期或時間快照）。在dimmension表中，檢測到變化，插入新的尺寸，現有的尺寸被重新使用。在規範化的倉庫中，您通常會有某種修訂機制或存檔流程或生效日期，以保持唯一性。

在我看來，無論您的DW理念或體系結構如何，都應該保持這些行的獨特性。 （如你在評論中所述），你有一個包含每一列的索引，這可能不是一個非常有用的索引（在任何數據庫設計中）。你確定你的索引甚至被用於任何查詢嗎？它是否也被標記爲獨特的，是否違反了約束條件？無論如何，這是一個相當大的多列索引，與比較會相對昂貴 - 這可能會導致超時 - 您可以隨時修復連接中的問題以永久等待，但我會從一個設計視角。

Answer 2

數據倉庫在加載前先做drop索引和約束，然後重新創建它們是很常見的。 如果您擺脫了限制（FKs），請確保您的加載過程處理此問題。刪除任何檢查限制，並將檢查驗證移入ETL軟件中，

Answer 3

140K不是很多行。 請張貼您的餐桌設計和插入失敗時您收到的錯誤

Answer 4

我會建議以下內容：保留所有數據，除了今天在單獨的表格中（讓我們稱之爲歷史記錄），其中索引被調整爲你的報告。將今天的數據保存在另一個單獨的表格中（讓我們稱它爲Today）並在午夜運行作業以將數據從Today表格移動到History表格。在今日表格 - 你應該有最小的索引來提高插入性能。 通過實施此設計，您將確保您的報告不會佔用插入內容。另外 - 你有兩個表爲他們的目的調整。一般而言，快速插入和快速選擇都很難調整表格。