拆分大表以提高性能
這是對較早問題的後續處理。我有一個 SQL Server 2008 R2 標準伺服器，它擁有一個數據庫，除了一個大表之外，它本身幾乎什麼都沒有。
該表有 100+ 百萬行（35 列），並且每天增長約 250,000 行。我們需要所有數據都“線上”，並且大多數列都需要以某種方式進行搜尋。桌面上的絕大多數活動是閱讀；除了
INSERT白天編輯的新數據外，無需更改任何內容。使用者對錶執行一系列查詢，從簡單的查找記錄請求到根據一系列條件提取數万行。我們對正在執行的查詢的控制有限，而且性能開始受到影響，即使是索引也是如此。
問題的很大一部分是磁碟 I/O，我們正在通過改造基於 SSD 的陣列來解決這個問題。由於所有數據庫文件都將在這個新陣列上，因此共識是擁有多個數據庫文件不會有任何區別，但將表拆分為單獨的表可能是可行的方法。
我現在很困惑什麼是最好的方法。我正在與自己辯論的兩個想法：
- 將表拆分為“層”
- 包含上週數據的表，這是
INSERT每天編入 的數據
- 下一個表格包含從上週回溯到前 3 個月
- 下一個包含 3 個月到 6 個月的表格
- 下一個表格包含 6 個月以上的任何內容然後，我將在一夜之間將數據“洗牌”（數據庫僅在上午 8 點到晚上 10 點訪問，所以我有一夜的時間來處理數據）。
- 為數據范圍創建表
- 為數據范圍創建一個表 - 例如每季度。然後我會將數據
INSERT輸入到 2013 年第 2 季度的表格中，然後轉到 2013 年第 3 季度、2014 年第 4 季度等…如果這樣可以提高性能，我可以使用文件組將舊表設為“只讀”。選項 1 對我來說是最容易實現的，但我不確定這是否是一個完全瘋狂的想法。選項 2 是一項需要更多實施和維護的工作，但如果它是解決此類問題的“最佳實踐”，那麼這就是我要走的路。
我們將不勝感激地接受任何和所有建議或替代想法 - 我認為這些問題最好在設計時解決。
我個人會選擇你的第一個選擇。如果您使用 `DELETE dbo.p1 OUTPUT INTO dbo.p2’ 模式來移動數據，那麼不會有很多事情會失敗。如果您分批使用大約 10K 行，那麼在您擁有的時間範圍內以這種方式移動 250K x 3 行應該不是問題。
我看到的基於更常見的基於日曆的分區的優勢是您的“分區”保持相同的大小。對於您正在處理的數據量，基於日曆的分區方法在月初工作得很好，而在月底可能會明顯變慢。
我和 Kalen Delany 一起寫了一篇關於“隨著時間的推移將數據從一個分區移動到另一個分區”方法的優點的文章： http ://sqlmag.com/database-administration/using-table-partitions-歸檔舊數據 oltp 環境
那篇文章使用的是企業專用的內置分區功能，但您也可以使用手工製作的多表分區來實現它。
我會嘗試將不同的表（分區）放在不同的驅動器上。由於舊分區中的數據僅在停機期間更改，因此您仍然可以在白天將這些文件組標記為只讀。或者，您可以使用
TRANSACTION ISOLATION READ UNCOMMITTED或READ COMMITTED SNAPSHOT隔離。假設您確實從未更新數據，後者也應該加快“目前”分區的速度。但即使有更新，它也可能會有所幫助。無論哪種方式，請確保在您的環境中測試性能。（無論如何，不要UNCOMMITTED在活動表/分區中使用，因為您讀取查詢可能最終會看到一半寫入的行，具體取決於您使用的數據類型。）