多欄位主鍵或“人為”“半人工”鍵的性能
這不是關於在任何給定表中使用人工自動增量鍵與使用多欄位“主鍵”的好處或其他方面的問題。任何想要搜尋它們的人都可以輕鬆找到該討論（或論點）並做出決定。
這個問題更多的是關於鍵的性能（或缺少鍵）
我是一名數據庫管理員，當我創建表時，我嘗試為表使用“自然”鍵。通常這是一組 2,3，有時是 4 個欄位，它們充當給定表的主鍵。通常這些欄位本質上是 Varchar，但很短（最多 10 或 15 個字元）。就我個人而言，我盡量讓它們更短！
我的問題是這個。
想像一下，我有一個包含人口統計數據的表格。我可以確保我在每一行中具有唯一性的唯一方法是使用 FirstName FamilyName DateOfBirth PlaceOfBirth 的欄位
（您可能想知道為什麼我包括“出生地”，我知道另一個人（他曾經住在附近 - 相同的電話號碼，不同的撥號程式碼）與我分享了所有這些詳細資訊（我假設 PlaceOfBirth 不同，但我想我可以使用 MothersMaidenName ;) )
所以現在我有一個有趣的問題。
我可以使用一個更短的欄位，它是通過連接 4 個主要欄位中的資訊創建的，例如： DateOfBirth First 2 characters of FirstName first 2 characters of FamilyName first 2 character of PlaceOfBirth
我的問題是這個。
與直接使用欄位（即有多少列）相比，欄位的連接在什麼時候會提供性能改進。
我從搜尋中知道，大多數 DBMS 都有一個“理論上的最大大小限制”，具體取決於創建的 B-Tree。我假設我在主鍵的長度/大小方面沒有達到這個限制。
我考慮使用這種“人為”鍵的原因是：連接列中的資訊很可能足以辨識記錄，而無需提取所有主鍵欄位（這對性能更好還是沒有？與使用所有 4 個主鍵欄位相比有何不同？）
這顯然是一個相當“理論”的問題，但我考慮過在一個最終有 4 個 varchar 欄位的表上進行這種連接，很明顯，只使用一個縮短版本就可以描述唯一性。顯然，首先要努力創建這個領域，但在其他人看來，這種努力是否值得，在什麼時候它會變得更有趣。
我已經搜尋過這個，但我從來沒有發現直接問過這個問題，它作為一個“自然”或“人工”的主鍵討論出現了。
當然，如果這感覺像是“自然”或“人為”的關鍵討論，請隨意說出來。我的感覺是，這個“人為”的鍵會提供兩者的優點。有沒有人在現實世界的解決方案中使用過這個想法？
提前感謝您的想法。
大衛
編輯。我剛找到這個執行緒
https://stackoverflow.com/questions/3735390/best-primary-key-for-storing-urls
它似乎涵蓋了類似的領域，我必須承認我沒有想過將我的列“散列”在一起（主要是因為它們本質上很短），但我確實喜歡這個想法。我想你可以這樣做並散列整行！
編輯2。
我回到這個問題只是想看看答案是否有任何變化或額外的評論。我已決定接受回复，但想指出，我發現所有回復對討論條款都有幫助。
我會斜著回答…
自然鍵始終是自然鍵，應使用唯一約束或索引強制執行。這是從您的建模階段流出的“主鍵”。
自動編號/身份代理鍵的選擇在實施階段很重要，因為您的**聚集索引有好的和壞的選擇（例如：SQL Server、Sybase、MySQL InnoDB、Oracle IOT）。
也就是說，主鍵與您的聚集索引正交：不要混淆這兩個問題
在這方面，我建議使用人為的鍵不會比使用自動編號/身份列增加任何價值。您從自然鍵中失去數據，可能不會是唯一的，同樣不透明。
FWIW，我也需要時使用代理鍵和復合鍵：
- 一些自然鍵本身就很有用：ISO 貨幣和國家程式碼
- 沒有二級（非聚集）索引和子表的表不能從代理鍵中受益
- 如果您有父子孫子，那麼我通常需要加入父孫子：使用複合鍵我可以直接這樣做。更簡單的 JOIN，更簡單的索引
注意：這假設每個表都需要一個聚集索引
dba.se 相關：SQL Server 主鍵/聚集索引設計決策