主鍵僅在主表上作為組合

Question

我們的環境中有一張桌子。 最近，發現通過對日期時間進行排序可以大大提高性能，dba希望將其作為主鍵。 由於他不能保證日期時間的唯一性，因此他將曾經是主鍵的ID添加到了新的組合鍵中。

因此，存在一個主鍵為datetime / id的表，並且聚簇索引也以此方式定義。 所有的pk / fk關系仍然正確設置，並且存在於人們期望的id到id范式中。

主鍵偏斜的可能是什么問題？

通過此更改，性能大大提高。

但是，在架構中，實際的“主鍵”是兩列。 可能出什么問題了？

Answer 1

不要那樣做！ 使用兩個字段設置唯一索引。 它不必是主鍵。 實際上，如果您希望原始密鑰保持唯一，那么這是一個糟糕的主意。

Answer 2

編輯：這個答案是假設Sql Server。 如果事實並非如此，那么我將刪除答案。

您沒有列出詳細信息，所以我將給出一個非常籠統的答案。 在我的研究中，我發現大多數人都會推薦一個簡短的主鍵/聚集索引。

不過，真正的關鍵是提高性能的意思。 只是一個查詢嗎？ 換句話說，此更改是否會對此數據的所有操作產生有益的影響，或至少沒有影響？ 用戶界面，所有報告等。 還是這個搶劫彼得來支付報酬？

如果這是大多數報表基於日期的報表數據庫或數據倉庫，那么我可以理解為什么人們會建議采用聚集索引設置的方式，使所有報表或最重要的報表受益。

在任何其他情況下，我都可以想到擁有一個非聚集索引將提供幾乎相同的級別或性能提升，而不會增加PK的大小，該PK用於所有查找（讀取更多字節=降低性能）以及占用數據頁上有更多空間。

編輯：本文比我更好地解釋了此主題。

https://www.simple-talk.com/sql/learn-sql-server/effective-clustered-indexes/

Answer 3

您當前看到的性能優勢（如果是正版的）是由於與主鍵關聯的聚集索引，而不是主鍵本身。 如果您對當前索引感到滿意，但又擔心唯一性，則應將唯一的datetime / id保留為聚集索引，但應恢復為原來的唯一id作為主鍵。

這也解決了以下問題：引用該主鍵的其他表可能需要創建可能不合適的datetime列來創建外鍵關系。