大桌子和糟糕的性能 - 下一步該怎麼做？
我們有一個 Windows 2008 R2 / SQL Server 2008 R2（標準）伺服器，用於託管單個數據庫。數據庫本身主要由一個包含實時數據和歷史數據的大表組成。該表目前有 35 列的 1.01 億行，並且以每天大約 250,000 行的速度增長。不幸的是，由於大量遺留程式碼，將表拆分為較小的表並不是一個真正的選擇。
數據庫本身（大約 100Gb）作為單個文件保存在單個 SSD 驅動器上。伺服器有另外兩個 10K SAS 磁碟用於引導作業系統、分頁等，伺服器有 22Gb 的 RAM。
儘管一切正常，但我們有幾十個使用者需要查詢此表中的數據。我們對這些查詢的控制有限：有時它從昨天提取幾百行，有時從 6 個月前提取數万行。99.9% 的活動是讀取行；除了
INSERT全天編輯的實時數據外，幾乎沒有什麼寫作。在高峰時間，返回大量數據的簡單查詢可能需要半小時或更長時間才能完成。我們有可用的索引，但最終的瓶頸似乎是磁碟 I/O。現有的 SSD 並不是最快的，因此我們正在考慮改裝 RAID1+0 陣列的高端 SSD 驅動器以提高性能（我們已經檢查過陣列卡可以處理吞吐量）。
假設我們有這個數組，那麼增加對該數據庫的讀取吞吐量的最佳計劃是什麼？如果我們有一個超快的 SSD 陣列，這就足夠了嗎？或者將數據庫分區到單獨的邏輯驅動器上的單獨文件是一個更好的主意，即使它們本質上是用於相同的磁碟？同樣，將數據庫和日誌文件拆分到同一陣列中的邏輯驅動器上會有什麼不同嗎？
如果您使用的是企業版，我建議您進行分區。單獨邏輯驅動器上的單獨文件不太可能提供太多幫助，因為數據都通過同一個控制器並寫入同一個底層磁碟（並且沒有分區，您對比例填充沒有太多控制，這意味著許多查詢將無論如何，可能仍然需要訪問幾個或所有文件）。
由於您沒有使用 Enterprise Edition，因此一種替代方法是將數據拆分為多個表，然後使用視圖將它們組合在一起。假設舊數據不再更新，您甚至可以將其放在只讀文件組中，這將減輕一些資源爭用。您可以根據需要使查詢邏輯變得複雜和挑剔；例如，最簡單的解決方案是針對視圖發出所有查詢，但您的數據訪問層或儲存過程邏輯可以 - 基於日期範圍參數 - 決定在執行時訪問哪些表。您甚至可以使用過濾索引，以便某些視圖將提取非常有限的數據子集，即使是從其自己的表中存在的子集中。這不是
當然，最便宜的解決辦法是在問題上投入硬體：具體來說，這樣你的數據庫就可以放入記憶體中。RAM 很便宜，假設你的盒子支持它，我會說從 22 GB（什麼奇數？）升級到
12864 GB 會有很長的路要走。（如果作業系統也是標準的，即使是 32 GB 也可能有幫助，但沒有那麼多。）雖然我很想看到一個實際的執行計劃和統計 I/O 指標的查詢需要半小時才能從SSD，如果大部分數據在記憶體中，它會快得多。