這個問題是針對MySQL的，因爲這是我正在使用的 - 但我認爲它可能幾乎每個主要數據庫實現都是相同或相似的。瞭解數據庫中的密鑰
密鑰如何在數據庫中工作？我的意思是，當你將一個字段設置爲'主鍵'，'唯一鍵'或'索引'時，每個字段都做了什麼，我應該什麼時候使用它們？
現在我有一個包含幾個字段的表，其中一個是GUID（減去{和}）。我將GUID字段設置爲主鍵，並且我看到它創建了一個二叉樹。因此它可以提高搜索性能 - 但是與其他類型的密鑰區別的是什麼？我知道這可能不是真正的編程相關（雖然它是與開發有關的） - 我不確定究竟在哪裏問這個問題，但是這是我使用最多的，所以我會在這裏問。根據需要遷移
在網絡上其他地方可能有數百個參考文獻，所以Google的一些內容將幫助您深入瞭解數據庫設計。這就是說，基本要點是：
在最基本的主鍵代表記錄將如何物理存儲在內存中/磁盤上，你會想要最獨特的領域，因爲它將大大減少搜索。
唯一鍵是隻能包含唯一值的字段。
索引是查詢可引用的數據庫文件的專用「映射」。
這些都是非常簡單的答案，但我認爲這是它的要義。
定義主鍵時，數據庫會根據該鍵創建索引。它需要是獨一無二的。一般來說，您可以創建一個索引來加速基於非唯一查詢數據的數據訪問。唯一鍵控數據的索引檢索時間應該比非唯一鍵控索引更好，所以我儘可能使用唯一索引。
還有一件事，任何鍵本質上都是一個單獨的表，按照索引排序，該索引直接指向與鍵匹配的行。 BTree風格索引存儲在一棵平衡樹中，平衡樹是一個樹形結構，其中左移越小，右移越大。
5
3 7
2 4 6 8
將是一個平衡樹的例子。另一種主要類型是哈希，其中數學表達式將密鑰轉換爲密鑰的相對內存位置。
爲了真正理解按鍵，您必須在三個層次上理解它們：概念，邏輯和物理。我要扭轉我的慣常秩序，首先討論身體。
大多數程序員傾向於在物理層面思考。在物理層面，一個關鍵是一個地址的代理（替代）。當要引用一行時，可以使用該鍵的副本來指定該行。當在另一行中引用一行時，該副本被稱爲外鍵。
大多數有經驗的程序員都對指針和地址有一個透徹的理解，並且只要它使用指針和地址就能準確理解數據結構是如何工作的。在關係數據庫成爲主導之前，實際上有數據庫使用指向嵌入在其他記錄中的記錄的指針來將數據綁定在一起。
使用鍵而不是指針的一個缺點是DBMS必須使用索引將鍵引用轉換回指針才能檢索有問題的行。一個好處是，只要DBMS相應地更新所有相關索引，間接級別就允許DBMS無論出於何種目的都對錶中的所有行進行整理。
在這個級別上看，鍵可能是簡單的，整數和自動增量。這些工作比其他類型的鍵快，並且避免了用戶提供的數據丟失或不一致時出現的某些數據管理問題。但是，在這個層面迴避數據管理問題可以在兩個較高層次上創建一個雷區。
在邏輯層面上，鍵是元組（行）中數據的最小子集，允許指定單個匹配元組，當DBMS檢索該元組的容器時，該元組中的所有屬性元組現在可用。每個關係至少有一個候選關鍵字。在最壞的情況下，整個元組是唯一的候選鍵。當單個關係（表）存在多個候選鍵時，通常的做法是選擇一個候選鍵作爲主鍵，並通過該主鍵進行所有引用。
（其實，關係和表不是同義詞，但我在這裏簡單化。同樣，元組和行不是同義詞，儘管它們看起來乍看是相同的。）
的主要原因申報初級關鍵是排除重複的鍵或丟失的鍵。 有時，數據庫人員會選擇將重複和丟失鍵保留給應用程序寫入數據庫的程序員。更常見的情況是，主鍵約束用於將錯誤反映回違反主鍵約束的程序。
當DBMS設置主鍵約束時，它還會在主鍵上構建索引。這允許DBMS快速查找重複項，並且還可以加快使用關鍵列的某些查詢。
在概念層面，關鍵是通過用戶社區標識實體實例的方式，這些實體是否者（員工，旅客等），東西（銀行帳戶，酒店客房等）或任何。密鑰是數據，密鑰標識的實體不是數據。因此可以將密鑰視爲數據庫中實體的替代物。
在概念層次，按鍵總是自然，也不會被系統自動供給。然而，在現實世界中，鑰匙往往管理不善，而管理不善的後果則被所謂的「常識」所克服。將常識灌輸到自動化系統中通常是不可行的。
我從來沒有真正在上述的指數，但它在我所說的隱式的。索引是一個數據結構，用於從一個鍵映射到一個指針。在您可能使用的所有數據庫中，索引由數據庫構建器（或者DBA）聲明並由DBMS管理。
謝謝你，一個基本的瞭解是所有我真的找了，我只是想確保我做出了正確的決定（並能保持作出正確的決定），當我添加一鍵表 – 2010-01-05 19:01:44
很好的回答。 FWIW，一些RDBMS允許具有唯一約束的列中有多個NULL。而你並沒有包括外鍵。 – 2010-01-05 19:02:15
比爾，因爲我剛剛注意到，OP是關於MySQL（這是允許多個空值具有唯一約束的RDBMS中的一個）明確要求，我將修改我的答案...你說得對。但OP沒有詢問外鍵...... – delfuego 2010-01-05 19:05:16