我應該用 200 萬行對我的主表進行分區嗎？
我是一名開發人員，需要一些 DBA 建議。
我們開始遇到 MSSQL2005 數據庫的性能問題。這些事件的明顯影響主要是伺服器上的 CPU 佔用，但操作報告說它也耗盡了 SAN 的資源（並非總是如此）。問題的主要來源肯定是在某些應用程序中，但我想知道我們是否應該對一些主表進行分區以減輕 I/O 壓力。
一個文件的基本容量約為 60GB。
主表（訂單）有 210 萬行和 215 個冒號（但沒有一個很大）。
我們有一個整數作為 PK，因此定義分區函式應該沒問題。
我們會通過分區贏得一些東西嗎？分區索引會給我們帶來什麼嗎？
以下是有關數據庫和表的更多事實
database_name database_size unallocated space My_base 57173.06 MB 79.74 MB reserved data index_size unused 29 444 808 KB 26 577 320 KB 2 845 232 KB 22 256 KB name rows reserved data index_size unused Order 2 097 626 4 403 832 KB 2 756 064 KB 1 646 080 KB 1688 KB感謝您的任何建議
判斷
啊——為什麼？15 年前，100 萬行被認為很小。今天，1 億行被認為很小。
如果你有一個 CPU-hog，我會開始尋找問題所在 - 這看起來更像是一個索引問題和/或糟糕的欄位設計而不是其他任何事情。
現在，SAN hogging - 這對於任何 SQL Server 來說都是完全正常的。SAN 人員通常對數據庫伺服器的 IO 很重這一事實非常無知。數據庫通常需要針對它們進行優化的特定 SAN 設置，並且可以被它們充分利用。它不是“佔用”它，它試圖盡可能好地使用所有資源。
您的數據庫很小 - 嚴重。我真的沒有在這裡看到任何問題。訂單表只有 4gb 的記憶體，這 - 足夠有趣 - 是一個應該從記憶體中回答的大小。
分區對於批量刪除很有用（每年一個表，刪除一年的訂單是表截斷，而不是刪除），但是對於您的大小，這不是問題（我有一個表 Prices 有大約 15 億個條目，那很小）。它不會加速查詢很多 - 要麼查詢只能選擇一個分區（不，整數 PK 沒有幫助，除非你選擇 PK 範圍作為過濾器） - 或者它不能。但即使可以，索引也幾乎一樣快。
什麼類型的查詢不好？執行計劃如何？可能是你：
- 記憶體太少（8gb 或更多？）
- 有一個次優/不匹配的索引佈局，以至於查詢基本上變成了表掃描？在這種情況下，我將開始修復那一側。
- 您載入的數據超出了您的需要？
如果沒有您的查詢執行計劃，這是無法回答的。
順便說一句，一個文件中有 60GB 是嚴重忽視。任何大型數據庫都應該有盡可能多的文件，因為有可能的並行操作（即 SQL Server 的可用伺服器核心）；）而且我確信您的 I/O 組織很糟糕 - 未對齊的分區，錯誤的格式，減慢您的速度（可能很多 - 糟糕的磁碟設置可能會使您損失高達 40% 的性能）。
放鬆 I/O 壓力：
- 確保您的數據庫伺服器已正確安裝（我很少看到 - 管理員似乎喜歡忽略此處的文件）
- 首先確保您擁有適當的資源。您在磁碟子系統上的 IOPS 預算有多高？你確實測量了它，或者？
- 確保數據庫設置正確（同樣，大多數管理員喜歡在這種情況下無知）
- 確保您具有良好的表結構和良好的主鍵（幾乎是您唯一正確的）。
然後 - 進入分析器，找出應用程序並確保優化此查詢。