表分區是否可以提高性能？這值得麼？

我剛剛參與了一個項目，我必須在該項目上開發一個數據遷移過程和一個使用現有 SQL Server DB 的 Web 界面。這個數據庫是幾年前由另一個人開發的，它有大約 100 GB 的數據，並且每 10 分鐘增加一次（它儲存來自多個單元的 10 分鐘數據 -> 每台設備每天 144 條記錄）。幾個表有大約 1000 萬行。關鍵是我認為主表的設計方式不是最有效或不適合通常執行的查詢類型。現在我需要證明我所說的是否比已經實施的更好。數據庫的表數量眾多，但結構可以通過下圖進行簡化：

Date_Id 欄位由使用 DateTime 欄位的函式自動生成。兩個表中都有兩個索引。每個表的聚群索引包含相同順序的 PK 欄位。Unit 表的第二個索引僅包含 Unit_Id 欄位，而 UnitData 中的第二個索引按此順序包含 Unit_Id 和 DateTime 欄位。

但是，我認為設計應該是這樣的：

在這種情況下，只需要 PK 欄位的聚集索引。對於這個 DB 設計，通常的查詢類似於：

SELECT ud.*
FROM Unit u, UnitData ud
WHERE u.Unit_Id = ud.Unit_Id and ud.DateTime >= 'dd-MM-yyyy'
ORDER BY ud.Unit_Id, ud.DateTime

現在出現了我真的不明白的事情：有人告訴我，擁有 Date_Id 列的唯一原因是將其用作該表的分區列。我已經詢問過對這個表進行分區的真正必要性，答案是“在需要每日或每月數據時更有效地執行查詢”。在此之前我對分區不太了解，所以我檢查了這些連結：

http://msdn.microsoft.com/en-us/library/ms190787.aspx

表分區有什麼幫助？

通過分區提高性能

考慮到理想的查詢將按設備和日期時間過濾，問題是：

1. 對於第一個數據庫設計（帶分區），您認為最有效和最理想的查詢是什麼？
2. 您真的認為針對第一個數據庫設計的最有效查詢比第二個（我在上面寫的那個）更好嗎？
3. 如果前一個是肯定的，你真的認為改進值得擁有兩個額外欄位（Id 和 Date-Id）和一個額外的索引嗎？

非常感謝！！

如果分區方案是為您的特定查詢而建構的，那麼使用分區只會幫助您提高查詢性能。

您將不得不檢查您的查詢模式並查看它們是如何訪問表的，以便確定最佳方法。這樣做的原因是您只能對單個列（分區鍵）進行分區，這將用於分區消除。

有兩個因素會影響分區消除是否發生以及它的執行情況：

1. 分區鍵- 分區只能發生在單個列上，並且您的查詢必須包含該列。例如，如果您的表按日期分區並且您的查詢使用該日期列，則應該進行分區消除。但是，如果您在查詢謂詞中不包含分區鍵，則引擎無法執行消除。
2. 粒度——如果你的分區太大，你不會從消除中獲得任何好處，因為它仍然會拉回比它需要的更多的數據。然而，把它做得很小，它變得難以管理。

在許多方面，分區就像使用任何其他索引一樣，具有一些額外的好處。但是，除非您處理非常大的表，否則您不會意識到這些好處。就個人而言，我什至不考慮分區，直到我的表大小超過 250 GB。大多數情況下，定義良好的索引將涵蓋小於該值的表上的許多案例。根據您的描述，您沒有看到巨大的數據增長，因此正確的索引表可能對您的表執行得很好。

我強烈建議您查看分區是否真的需要解決您的問題。人們通常會為了以下目的對一個非常大的表進行分區：

• 在不同類型的磁碟之間分配數據，以便可以將更多“活動”數據放置在更快、更昂貴的儲存上，而將較少活動的數據放置在更便宜、更慢的儲存上。這主要是一種成本節約措施。
• 協助維護超大表的索引。由於您可以單獨重建分區，因此這有助於以最小的影響正確維護索引。
• 利用分區改進歸檔過程。見滑動視窗。

引用自：https://dba.stackexchange.com/questions/62707