存檔表是否應該有自己的代理身份密鑰

歸檔表是否應該有自己的代理身份 ID/密鑰？對於客戶銷售表範例：

• 我們有原始表，然後是一個帶有代理存檔 ID 的附加存檔表。

• 主聚集索引的規則是：

  • 不斷增加
  • 狹窄的
  • 獨特
  • 靜止的

參考： 有效聚集索引（Red-Gate Hub）

在我工作的最後一家公司，有一個想法，如果我們不小心錯過了導入的一天或一段時間，例如導入 5 月 3 日的數據，不小心跳過了 5 月 4 日（系統問題），並導入了 5 月 5 日，那麼如果沒有新的存檔 id，我們將不得不在頁面之間重新插入數據，從而導致碎片和插入速度變慢。

使用存檔 id，我們可以以不斷增加的方式添加。

只需詢問添加 archiveid 列是否是標準的行業慣例。

原表：

create table dbo.CustomerSalesId
(
   CustomerSalesId bigint primary key identity(1,1),
   CustomerId bigint not null,
   PurchaseDate datetime not null,
   Amount decimal (10,2) not null,
   .........
}

存檔表：

create table dbo.ArchiveCustomerSalesId
(
   ArchiveCustomerSalesId bigint primary key identity(1,1),
   CustomerSalesId bigint,
   CustomerId bigint not null,
   PurchaseDate datetime not null,
   Amount decimal (10,2) not null,
   .........
}
create unique index ux_CustomerSalesId on ArchiveCustomerSalesId(CustomerSalesId)

碎片化並沒有你想像的那麼糟糕。頁面完整性（內部碎片）比頁面的物理順序（外部碎片）重要得多。

從磁碟讀取頁面時，亂序插入行可能會影響掃描性能。從記憶體中讀取頁面時，頁面的順序是否正確並不重要。此外，您可能沒有使用物理伺服器，並且您的磁碟可能是位於 SAN 上的 LUN，因此頁面連續性的優勢可以忽略不計。

可以在此處找到內部碎片與外部碎片的良好視覺描述：http ://www.sqlservercentral.com/blogs/practicalsqldba/2012/04/05/sql-server-index-fragmentation-understanding-fragmentation/

在 Brent Ozar 的部落格上可以找到一篇關於為什麼碎片化不是您所想的精彩文章：https ://www.brentozar.com/archive/2012/08/sql-server-index-fragmentation/

也就是說，為了避免碎片化而使用額外的代理鍵並不是一個好主意。首先，一個好的聚集索引是您用來定位數據的最常用的鍵，因此您不必執行額外的查找。如果在歸檔數據時更改集群鍵，要定位行，您必須在前一個集群鍵的列上使用唯一的非聚集索引。非聚集索引是需要額外空間的數據副本，並且還需要查找以提取不屬於索引的列。

總結：不，您不需要額外的“archiveId”代理鍵。

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