Sql-Server

分區表中PK的最佳選擇是什麼?

  • September 9, 2020

我有一個分區的大表(表名:)Trans。目前該表將在 32 個分區上創建。該表將包含大約 3 億條記錄,並且每天都會刪除超過 14 天的數據。此表中的一列是對包含多達 500 萬條記錄(表名:)的表的引用,Sens我還希望它被分區。我想問你:

  1. 兩個表都使用相同的分區函式會不會有問題?因此,該Sens表也將分佈在 32 個分區上,並將保存在與該Trans表相同的文件中。這是一個好方法嗎?
  2. Trans表有一個PK基於兩列TranID (Identity (1,1))ParititionID。目前,FK較小的表(‘Sens’)僅基於一列 - SenID。較小的表也必須進行分區。如果表PK中的Sens僅在IDENTITY (1,1)列上而不是IDENTITY (1,1)列上,那麼操作的方法/效率/速度會有什麼不同partition column,即
ALTER TABLE [dbo].[Sen]
ADD CONSTRAINT [PK_SenID]
   PRIMARY KEY CLUSTERED ([SenID] ASC) ON [PRIMARY];

-- or 

ALTER TABLE [dbo].[Sen]
ADD CONSTRAINT [PK_SenID]
   PRIMARY KEY CLUSTERED (
                             [SenID] ASC,
                             [PartitionID]
                         ) ON [psTrans]([PartitionID])
  1. 您是否曾經嘗試過計算分區列?我正在考慮根據基於表中其他列計算的新列選擇分區:

CAST(HASHBYTES('MD5', [othercolumnInTable]) AS tinyint) % 32

對於第一個問題,只要不需要更改分區函式的定義,對兩個表使用相同的函式就沒有問題。您提到刪除每日數據,並且您的分區功能計劃包含 32 個分區,因此我假設您每月每天創建一個分區。如果是這樣,我看不出您需要合併或拆分分區的原因。話雖如此,鑑於您只涉及兩個表,因此創建兩個單獨的函式也沒有任何問題。

這兩個表是否應該存在於相同的數據庫文件中取決於您如何定義文件和文件組。鑑於您只保留 14 天的數據並清除其餘數據,我假設您沒有將某些分區放在不同的儲存類別上。表中的 500 萬行Sens確實不是一個很大的數字,因此使用沒有表的相同數據庫文件可能不會有問題。這只是基於不完整資訊的猜測。

對於第二個問題,評估分區對齊索引是否適合該表:

建立在與其對應表相同的分區方案上的索引。當表及其索引對齊時,SQL Server 可以快速有效地切換分區,同時保持表及其索引的分區結構。索引不必參與相同的命名分區函式以與其基表對齊。但是,索引和基表的分區功能必須本質上是一樣的,在於:

  1. 分區函式的參數具有相同的數據類型。
  2. 它們定義了相同數量的分區。
  3. 它們為分區定義了相同的邊界值。

我自己的觀點是,除非您有充分的理由,否則您不應該對具有 500 萬行的表進行分區。分區是為大型表設計的功能。為什麼需要對 500 萬行的表進行分區?

對於最後一個問題,我使用了具有計算分區列的分區表。我不推薦它,除非你別無選擇。我們一直遇到奇怪的問題,包括分區消除沒有按預期工作。

非常感謝您的全面回答。這個想法是有32個分區,16個文件和8個文件組。換句話說,每個filegroup都應該包含2文件(即總4分區)。老實說,這是我第一次設計大型數據庫,我必須創建一個新的file group並使用分區。因此,上述數字是指示性的。你有什麼方法可以正確劃分文件、文件組和分區嗎?

關於Trans表的分區,分區列將是Tinyint類型。分區遵循業務邏輯並將所有數據(大約 3 億條記錄)分成大致相等的部分(或者至少這是假設)。因此,分區將不是按日期,而是按類型的列Tinyint

我們希望利用Trans表分區的優勢,因為它將包含大量數據,即大約 3 億條記錄。此外,它將有大約 60 列。此外,要求數據庫inserts每秒可以管理該表300次,同時對該表進行大約250次update操作。所以我明白,通過對這張表進行分區,有許多操作insertupdate我們將同時執行多個文件,這應該可以加快速度並處理需求。雖然也許我的解釋是錯誤的?

除了Sens我在這裡描述的表之外,還會有一個Events表,它將對Trans錶的 PK 進行 FK 引用,並且將包含大約 100-2 億條記錄。總結一下我目前認為要分區的表是Trans(大約3億條記錄), Sens(大約500萬條記錄),Events(大約100-2億條記錄)。它們都將使用相同的分區功能,即它們將存在於 32 個分區、16 個文件和 8 個文件組中。桌上應該有300個inserts,每秒Trans250~290個。表中每秒updates應該有 200-300次操作。每秒應該有大約 400-500 次插入update``Sens``Event桌子。將它們全部分區的主要原因不是要對一個數據庫文件執行所有這些操作,而是要正確分配它。您寫道,您有分區經驗。您認為分區是否適合這些要求?

至於數據刪除。每天,超過 14 天的數據將從TransEvents表中刪除。我想這樣做的方式是,通過該操作,Delete我分別為每個分區刪除數據。我沒有這方面的經驗,我不知道這是否是最有效的選擇。此外,該解決方案將作為 AlwaysOn 的一部分創建(因此可能存在一些限制)。

引用自:https://dba.stackexchange.com/questions/275145