在SQL Server 2008中對查詢性能進行分區

Question

我有一個場景，其中有大量關於項目的狀態數據。 該項目的狀態從分鍾更新到分鍾，並且在不久的將來將有大約50,000個項目。 因此，在一個月內，將有大約2,232,000,000行數據。 在獲得舊數據之前，我必須在主表中保留至少3個月。

我必須計划根據特定項目（其ID）和數據范圍（通常最多一個月的范圍）實現快速查詢 - 例如，從Table中選擇A，B，C，其中ItemID = 3000，日期介於'2010-之間10-01'和'2010-10-31 23：59：59.999'

所以我的問題是如何設計一個分區結構來實現這一目標？

目前，我基於“項目的唯一標識符”（一個int）mod“分區數”進行分區 ，以便所有分區均勻分布。 但它的缺點是在表上保留一個額外的列作為分區函數的分區列，因此，將行映射到其分區。 所有這些都增加了一些額外的存儲空間。 此外，每個分區都映射到不同的文件組。

Answer 1

從未對查詢性能進行分區。 通過分區，性能總是會更糟，你可以期待的最好的是沒有大的回歸，但永遠不會改進。

對於查詢性能，分區可以做什么，索引可以做得更好，這應該是你的答案：索引適當。

分區對IO路徑控制情況（在歸檔/當前卷上分發）或ETL負載中的快速接入切換方案很有用。 所以我會理解你是否有一個滑動窗口和按日期分區，這樣你就可以快速切換出不再需要保留的數據。

分區的另一個小例子是最后一頁插入鎖存器爭用，如解決高度並發INSERT工作負載上的PAGELATCH爭用中所述。

您的分區方案和用例似乎不適合它將受益的任何場景（ 可能是最后一個場景，但從描述中不清楚），因此很可能會傷害性能。

Answer 2

我真的不同意Remus Rusanu。 我認為如果存在邏輯原因（與您的用例相關），分區可能會提高性能。 我的猜測是你只能在itemID上進行分區。 另一種方法是使用日期，但是如果你無法預測日期范圍不會越過給定分區的邊界（沒有查詢肯定是一個月），那么我會堅持使用itemId分區。

如果只需要計算幾個項目，另一個選項是覆蓋索引：在主要區分字段（itemId）上定義一個INDEX，它包含您需要計算的字段。

CREATE INDEX idxTest ON itemId INCLUDE quantity;

Answer 3

應用分區實際上可以有利於查詢性能。 在您的情況下，您有50K項和2G行。 例如，您可以創建500個表，每個表名為status_nnn，其中nnn介於001和500之間，並且在這些表中將您的項狀態“分區”，其中nnn是項目ID的函數。 這樣，給定項目ID，您可以先將搜索限制為整個數據的0.2％（約4M行）。

這種方法有很多缺點，因為你可能不得不處理動態sql和其他令人不快的問題，特別是如果你需要聚合來自不同表的數據。 但是，它肯定會提高某些查詢的性能，你提到的那些。

基本上，應用程序分區類似於創建非常寬且平坦的索引，針對非常特定的查詢進行了優化，無需復制數據。

應用程序分區的另一個好處是，理論上（根據您的用例）您可以在不同的數據庫甚至不同的服務器之間分配數據。 同樣，這在很大程度上取決於您的具體要求，但我已經看到並使用了大量數據集（數十億行），其中應用程序分區非常有效。