SQL主鍵 - 複雜的主或字符串串聯？

Question

我有一張16列的表格。它將成爲網絡應用中最常用的表格，它將包含大約幾百行。數據庫是在sql server 2008上創建的。

我的問題是主鍵的選擇。什麼更快？我可以使用複雜的主鍵與兩個bigint-s或我可以使用一個varchar值，但我需要連接它後？

Answer 1

還有更多的因素必須考慮：

• 數據訪問模式盛行，你怎麼來訪問表？
• 多少個非聚集索引？
• 頻率更新
• 模式的更新（順序插入，隨機）刪除

所有這些因素，以及專門的前兩個

模式，應該推動您的聚集鍵的選擇。請注意，主鍵和集羣鍵是不同的概念，經常會混淆。請閱讀我在Should I design a table with a primary key of varchar or int?上的回答，詳細討論推動聚類關鍵選擇的標準。

沒有關於您的訪問模式的任何信息，我可以非常簡短而且簡潔地回答，並且實際上是正確的：更窄的密鑰總是更快（出於IO的原因）。但是，這種迴應毫無價值。唯一能夠讓你的應用程序更快的方法是在查詢執行計劃中選擇一個將被用於的密鑰。

Answer 2

爲什麼不只是一個INT自動生成的主鍵？ INT是32位的，所以它可以處理超過40億條記錄。

CREATE TABLE Records (
    recordId INT NOT NULL PRIMARY KEY, 
    ... 
); 

Answer 3

不依賴任何基礎值的主鍵（稱爲surrogate key）是一個不錯的選擇。這樣，如果行更改，ID不必，並且任何引用它的表格（Foriegn Keys）都不需要更改。我會爲主鍵列選擇一個自動編號（即IDENTITY）列。

就性能而言，較短的基於整數的主鍵最好。

您仍然可以在多列上創建聚簇索引。

Answer 4

該決定依賴於它的使用。如果您正在使用該表來保存數據，而不是檢索它，那麼只需一個簡單的鍵。如果您主要查詢數據，並且它主要是靜態數據，其中鍵值不會更改，則您的索引策略需要將數據優化爲將使用的最頻繁查詢。就我個人而言，我喜歡使用GUID作爲主鍵，而使用int作爲聚集索引。這可以輕鬆導入數據。但是，這確實取決於你的需求。

Answer 5

你是什麼意思更快？如果您需要更快搜索，則可以爲任何列創建索引或創建全文搜索。主鍵只是確保你沒有重複的記錄。

Answer 6

如果此表上有外鍵關係，代理鍵可能是個好主意。使用代理將保存引用它的表，而不必複製其表中的所有列。

另一個重要的考慮因素是您將在WHERE子句中使用的列的索引。如果你不這樣做，你的表現會受到影響。確保您在主鍵之上添加適當的索引，以避免表掃描。

Answer 7

您未提及的變量的批次;無論兩列中的數據是否是「自然的」，並且通過邏輯ID識別記錄是有益的，如果通過UI公開密鑰會帶來風險，性能有多重要（幾十萬行非常小） 。

如果你不是太挑剔，去速度和簡單的自動編號路徑。也請看看網站上關於SQL primary key types的所有帖子。這裏有大量的信息。

Answer 8

它是ER模型還是維度模型？在ER模型中，它們應該是分開的，不應該被替代。整個記錄可以有一個單一的代理以方便在URL中引用等。這可能是組合鍵或身份的所有部分的散列。

在維度模型中，它們也必須是分開的，它們都應該被替代。