SQL數據庫最佳實踐 - 使用歸檔表？

Question

我不是一個受過訓練的DBA，但執行一些SQL任務，並有這樣的疑問：

在SQL數據庫中我注意到，模仿另一個表具有完全相同的領域和使用檔案表用於接受當該數據被視爲歸檔時，原始表中的行。由於我已經看到這些表位於同一個數據庫和同一個驅動器上的示例，我的假設是這樣做是爲了提高性能。這樣的表沒有比他們大約10萬行更多...

• 爲什麼會變成這樣而不是做使用列指定行的狀態，比如一個在布爾/活躍的旗幟？
• 什麼時候會提高性能？
• 考慮到數據可能仍然需要查詢（或與當前數據結合），最佳模式是什麼才能正確構造？
• 還有什麼可說的呢？

Answer 1

我說的這種情況頻繁，但是......相同結構的

多個表幾乎從來沒有有意義。

狀態標誌是一個更好的主意。有沒有適當的方法來提高性能（分區/索引），而無需對數據進行非規範化處理或以其他方式創建冗餘。現代rdbms世界上的1000萬條記錄是相當小的，所以你看到的是規劃不周或數據庫誤解的產物。

Answer 2

歸檔的概念是物理的，而不是邏輯的。邏輯上，歸檔表包含完全相同的實體，應該是同一個表。

身體問題往往是務實的。總體概念是「數據庫變得太（大/慢）」。歸檔記錄可以更輕鬆地執行以下操作：

1. 以不同的方式優化索引結構。歸檔表可以有更多的索引，而不會影響工作表上的插入/更新性能。此外，索引可以用完整頁面重新構建，而工作表通常希望具有50％完整和平衡的頁面。

2. 以不同的方式優化存儲介質。您可以將歸檔表放在速度較慢或較便宜的磁盤驅動器上，這些磁盤驅動器可能具有更多容量

3. 以不同方式優化備份策略。工作表可能需要熱備份或日誌傳送，而存檔表可以使用快照。

4. 如果您正在使用它，則可以不同地優化複製。如果歸檔表每天只通過夜間批量更新一次，則可以使用快照而不是事務複製。

5. 不同級別的訪問。也許你需要不同的歸檔表安全訪問級別。

6. 鎖定爭用。如果你的工作表非常熱，你寧願讓MIS開發人員訪問歸檔表，他們在運行某些內容時不太可能停止操作，而忘記指定髒讀取語義。

最佳做法是不要使用存檔表，而是從OLTP數據庫中的數據移動到MIS數據庫，數據倉庫，或者用非規範化的數據數據集市。但是一些組織將難以證明額外數據庫系統的成本（這並不便宜）。向現有數據庫添加額外表格的障礙要少得多。