MySQL主鍵 外鍵 索引

標籤：很多   主表   bsp   編寫   有一個   修改時間   粘合劑   entity   證明   

一、什麼是主鍵、外鍵：

關係型資料庫中的一條記錄中有若干個屬性，若其中某一個屬性群組(注意是組)能唯一標識一條記錄，該屬性群組就可以成為一個主鍵比如 ：

學生表(學號，姓名，性別，班級)

其中每個學生的學號是唯一的，學號就是一個主鍵

使用者表(使用者名稱、密碼、登入層級)

其中使用者名稱是唯一的, 使用者名稱就是一個主鍵

上機記錄表(卡號,學號,姓名、序號)

上機記錄表中單一一個屬性無法唯一標識一條記錄，學號和姓名的組合才可以唯一標識一條記錄，所以 學號和姓名的屬性群組是一個主鍵

上機記錄表中的序號不是成績表的主鍵，但它和學生表中的學號相對應，並且學生表中的學號是學生表的主鍵，則稱成績表中的學號是學生表的外鍵

定義主鍵和外鍵主要是為了維護關聯式資料庫的完整性，總結一下：

主鍵是能確定一條記錄的唯一標識，比如，一條記錄包括社會安全號碼，姓名，年齡。社會安全號碼是唯一能確定你這個人的，其他都可能有重複，所以，社會安全號碼是主鍵。

外鍵用於與另一張表的關聯。是能確定另一張表記錄的欄位，用於保持資料的一致性。比如，A表中的一個欄位，是B表的主鍵，那他就可以是A表的外鍵。

二、 主鍵、外鍵 和索引的區別

主鍵、外鍵和索引的區別？

定義： 唯一標識一條記錄，不能有重複的，不允許為空白 表的外鍵是另一表的主鍵, 外鍵可以有重複的, 可以是空值 
該欄位沒有重複值，但可以有一個空值作用： 用來保證資料完整性 用來和其他表建立聯絡用的 是提高查詢排序的速度個數： 主鍵只能有一個 
一個表可以有多個外鍵 一個表可以有多個惟一索引

 

叢集索引和非叢集索引的區別？叢集索引一定是唯一索引。但唯一索引不一定是叢集索引。

叢集索引，在索引頁裡直接存放資料，而非叢集索引在索引頁裡存放的是索引，這些索引指向專門的資料頁的資料。

三、資料庫中主鍵和外鍵的設計原則

主鍵和外鍵是把多個表組織為一個有效關聯式資料庫的粘合劑。主鍵和外鍵的設計對物理資料庫的效能和可用性都有著決定性的影響。必須將資料庫模式從理論上的邏輯設計轉換為實際的實體設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的資料庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。

主鍵：

關聯式資料庫依賴於主鍵---它是資料庫物理模式的基石。主鍵在物理層面上只有兩個用途：

1. 惟一地標識一行。

2. 作為一個可以被外鍵有效引用的對象。

基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：

1. 主鍵應當是對使用者沒有意義的。如果使用者看到了一個表示多對多關係的串連表中的資料，並抱怨它沒有什麼用處，那就證明它的主鍵設計地很好。

2. 主鍵應該是單列的，以便提高串連和篩選操作的效率。

註：使用複合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯誤的。其一是主鍵應當具有實際意義，然而，讓主鍵具有意義只不過是給人為地破壞資料庫提供了方便。其二是利用這種方法可以在描述多對多關係的串連表中使用兩個外部鍵來作為主鍵，我也反對這種做法，理由是：複合主鍵常常導致不良的外鍵，即當串連表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然而這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠後的從表，其主鍵將會包含越多的列了。

3. 
永遠也不要更新主鍵。實際上，因為主鍵除了惟一地標識一行之外，再沒有其他的用途了，所以也就沒有理由去對它更新。如果主鍵需要更新，則說明主鍵應對使用者無意義的原則被違反了。

註：這項原則對於那些經常需要在資料轉換或多資料庫合并時進行資料整理的資料並不適用。

4. 主鍵不應包含動態變化的資料，如時間戳記、建立時間列、修改時間列等。

5. 
主鍵應當有電腦自動產生。如果由人來對主鍵的建立進行幹預，就會使它帶有除了惟一標識一行以外的意義。一旦越過這個界限，就可能產生認為修改主鍵的動機，這樣，這種系統用來連結記錄行、管理記錄行的關鍵手段就會落入不瞭解資料庫設計的人的手中。

四、資料庫主鍵選取策略

我們在建立資料庫的時候，需要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性群組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新、刪除的時候不會出現張冠李戴的錯誤。當然，其它欄位可以輔助我們在執行這些操作時消除共用衝突，不過就不在這裡討論了。主鍵除了上述作用外，常常與外鍵構成參照完整性條件約束，防止出現資料不一致。所以資料庫在設計時，主鍵起到了很重要的作用。

常見的資料庫主鍵選取方式有：

? 自動成長欄位

? 手動增長欄位

? UniqueIdentifier

? “COMB（Combine）”類型

1自動成長型欄位很多資料庫設計者喜歡使用自動成長型欄位，因為它使用簡單。自動成長型欄位允許我們在向資料庫添加資料時，不考慮主鍵的取值，記錄插入後，資料庫系統會自動為其分配一個值，確保絕對不會出現重複。如果使用SQL 
Server資料庫的話，我們還可以在記錄插入後使用@@Identity全域變數擷取系統分配的主鍵索引值。

儘管自動成長型欄位會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在資料緩衝模式下，很難預先填寫主鍵與外鍵的值。

假設有兩張表：

Order(OrderID, OrderDate)

OrderDetial(OrderID, LineNum, ProductID, Price)

Order表中的OrderID是自動成長型的欄位。現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動成長型的欄位，那麼我們在記錄正式插入到資料庫之前無法事先得知它的取值，只有在更新後才能知道資料庫為它分配的是什麼值。這會造成以下矛盾發生：

首先，為了能在OrderDetail的OrderID欄位中添入正確的值，必須先更新Order表以擷取到系統為其分配的OrderID值，然後再用這個OrderID填充OrderDetail表。最後更新OderDetail表。但是，為了確保資料的一致性，Order與OrderDetail在更新時必須在事務保護下同時進行，即確保兩表同時更行成功。顯然它們是相互矛盾的。

除此之外，當我們需要在多個資料庫間進行資料的複製時（SQL 
Server的資料分發、訂閱機制允許我們進行庫間的資料複製操作），自動成長型欄位可能造成資料合併時的主鍵衝突。設想一個資料庫中的Order表向另一個庫中的Order表複製資料庫時，OrderID到底該不該自動成長呢？

ADO.NET允許我們在DataSet中將某一個欄位設定為自動成長型欄位，但千萬記住，這個自動成長欄位僅僅是個預留位置而已，當資料庫進行更新時，資料庫產生的值會自動取代ADO.NET分配的值。所以為了防止使用者產生誤解，建議大家將ADO.NET中的自動成長初始值以及增量都設定成-1。此外，在ADO.NET中，我們可以為兩張表建立DataRelation，這樣存在級聯關係的兩張表更新時，一張表更新後另外一張表對應鍵的值也會自動發生變化，這會大大減少了我們對存在級聯關係的兩表間更新時自動成長型欄位帶來的麻煩。

2手動增長型欄位既然自動成長型欄位會帶來如此的麻煩，我們不妨考慮使用手動增長型的欄位，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表格儲存體當前主鍵索引值。還用上面的例子來說，這次我們建立一張表叫IntKey，包含兩個欄位，KeyName以及KeyValue。就像一個HashTable，給一個KeyName，就可以知道目前的KeyValue是什麼，然後手工實現索引值資料遞增。在SQL 
Server中可以編寫這樣一個預存程序，讓取索引值的過程自動進行。代碼如下：

CREATE PROCEDURE[GetKey]

@KeyNamechar(10),

@KeyValue intOUTPUT AS UPDATE IntKey SET @KeyValue =KeyValue = KeyValue + 1 
WHERE KeyName = @KeyName GO

這樣，通過調用預存程序，我們可以獲得最新索引值，確保不會出現重複。若將OrderID欄位設定為手動增長型欄位，我們的程式可以由以下幾步來實現：首先調用預存程序，獲得一個OrderID，然後使用這個OrderID填充Order表與OrderDetail表，最後在事務保護下對兩表進行更新。

使用手動增長型欄位作為主鍵在進行資料庫間資料複製時，可以確保資料合併過程中不會出現索引值衝突，只要我們為不同的資料庫分配不同的主鍵取值段就行了。但是，使用手動增長型欄位會增加網路的RoundTrip，我們必須通過增加一次資料庫訪問來擷取當前主鍵索引值，這會增加網路和資料庫的負載，當處於一個低速或斷開的網路環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮並發衝突等種種因素，這更會增加系統的複雜程度。

3使用UniqueIdentifierSQL Server為我們提供了UniqueIdentifier資料類型，並提供了一個產生函數NEWID( 
)，使用NEWID( 
)可以產生一個唯一的UniqueIdentifier。UniqueIdentifier在資料庫中佔用16個位元組，出現重複的機率非常小，以至於可以認為是0。我們經常從註冊表中看到類似

{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}

的東西實際上就是一個UniqueIdentifier，Windows用它來做COM組件以及介面的標識，防止出現重複。在.NET裡管UniqueIdentifier稱之為GUID（Global 
Unique Identifier）。在C#中可以使用如下命令產生一個GUID：

Guid u =System.Guid.NewGuid();

對於上面提到的Order與OrderDetail的程式，如果選用UniqueIdentifier作為主鍵的話，我們完全可以避免上面提到的增加網路RoundTrip的問題。通過程式直接產生GUID填充主鍵，不用考慮是否會出現重複。

UniqueIdentifier欄位也存在嚴重的缺陷：首先，它的長度是16位元組，是整數的4倍長，會佔用大量儲存空間。更為嚴重的是，UniqueIdentifier的產生毫無規律可言，要想在上面建立索引（絕大多數資料庫在主鍵上都有索引）是一個非常耗時的操作。有人做過實驗，插入同樣的資料量，使用UniqueIdentifier型資料做主鍵要比使用Integer型資料慢，所以，出於效率考慮，儘可能避免使用UniqueIdentifier型資料庫作為主鍵索引值。

4使用“COMB（Combine）”類型既然上面三種主鍵類型選取策略都存在各自的缺點，那麼到底有沒有好的辦法加以解決呢？答案是肯定的。通過使用COMB類型（資料庫中沒有COMB類型，它是Jimmy 
Nilsson在他的“The Cost of GUIDs asPrimary Keys”一文中設計出來的），可以在三者之間找到一個很好的平衡點。

COMB資料類型的基本設計思路是這樣的：既然UniqueIdentifier資料因毫無規律可言造成索引效率低下，影響了系統的效能，那麼我們能不能通過組合的方式，保留UniqueIdentifier的前10個位元組，用後6個位元組表示GUID產生的時間（DateTime），這樣我們將時間資訊與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心UniqueIdentifier減少到10位元組會造成資料出現重複，其實不用擔心，後6位元組的時間精度可以達到1/300秒，兩個COMB類型資料完全相同的可能性是在這1/300秒內產生的兩個GUID前10個位元組完全相同，這幾乎是不可能的！在SQL 
Server中用SQL命令將這一思路實現出來便是：

DECLARE @aGuidUNIQUEIDENTIFIER

SET @aGuid =CAST(CAST(NEWID() AS BINARY(10))

+ CAST(GETDATE()AS BINARY(6)) AS UNIQUEIDENTIFIER)

經過測試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類型要快上一些。

MySQL主鍵 外鍵 索引