一、什麼是主鍵、外來鍵：
關係型資料庫中的一條記錄中有若干個屬性，若其中某乙個屬性組(注意是組)能唯一標識一條記錄，該屬性組就可以成為乙個主鍵
比如 學生表(學號，姓名，性別，班級)
其中每個學生的學號是唯一的，學號就是乙個主鍵
課程表(課程編號,課程名,學分)
其中課程編號是唯一的,課程編號就是乙個主鍵
成績表(學號,課程號,成績)
成績表中單一乙個屬性無法唯一標識一條記錄，學號和課程號的組合才可以唯一標識一條記錄，所以學號和課程號的屬性組是乙個主鍵
成績表中的學號不是成績表的主鍵，但它和學生表中的學號相對應，並且學生表中的學號是學生表的主鍵，則稱成績表中的學號是學生表的外來鍵
同理成績表中的課程號是課程表的外來鍵
定義主鍵和外來鍵主要是為了維護關聯式資料庫的完整性，總結一下：
主鍵是能確定一條記錄的唯一標識，比如，一條記錄包括身份正號，姓名，年齡。身份證號是唯一能確定你這個人的，其他都可能有重複，所以，身份證號是主鍵。
外來鍵用於與另一張表的關聯。是能確定另一張表記錄的字段，用於保持資料的一致性。比如，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到底該不該自動增長呢？
允許我們在dataset中將某乙個字段設定為自動增長型字段，但千萬記住，這個自動增長字段僅僅是個佔位符而已，當資料庫進行更新時，資料庫生成的值會自動取代分配的值。所以為了防止使用者產生誤解，建議大家將中的自動增長初始值以及增量都設定成-1。此外，在中，我們可以為兩張表建立datarelation，這樣存在級聯關係的兩張表更新時，一張表更新後另外一張表對應鍵的值也會自動發生變化，這會大大減少了我們對存在級聯關係的兩表間更新時自動增長型字段帶來的麻煩。
2手動增長型字段
既然自動增長型字段會帶來如此的麻煩，我們不妨考慮使用手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表儲存當前主鍵鍵值。還用上面的例子來說，這次我們新建一張表叫intkey，包含兩個字段，keyname以及keyvalue。就像乙個hashtable，給乙個keyname，就可以知道目前的keyvalue是什麼，然後手工實現鍵值資料遞增。
在sql server中可以編寫這樣乙個儲存過程，讓取鍵值的過程自動進行。**如下：
create procedure [getkey]
@keyname char(10),
@keyvalue int output
asupdate intkey set @keyvalue = keyvalue = keyvalue + 1 where keyname = @keyname
go這樣，通過呼叫儲存過程，我們可以獲得最新鍵值，確保不會出現重複。若將orderid欄位設定為手動增長型字段，我們的程式可以由以下幾步來實現：首先呼叫儲存過程，獲得乙個orderid，然後使用這個orderid填充order表與orderdetail表，最後在事務保護下對兩表進行更新。
使用手動增長型字段作為主鍵在進行資料庫間資料複製時，可以確保資料合併過程中不會出現鍵值衝突，只要我們為不同的資料庫分配不同的主鍵取值段就行了。但是，使用手動增長型字段會增加網路的roundtrip，我們必須通過增加一次資料庫訪問來獲取當前主鍵鍵值，這會增加網路和資料庫的負載，當處於乙個低速或斷開的網路環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮併發衝突等種種因素，這更會增加系統的複雜程度。
3使用uniqueidentifier
sql server為我們提供了uniqueidentifier資料型別，並提供了乙個生成函式newid( )，使用newid( )可以生成乙個唯一的uniqueidentifier。uniqueidentifier在資料庫中占用16個位元組，出現重複的概率非常小，以至於可以認為是0。我們經常從登錄檔中看到類似
的東西實際上就是乙個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型資料庫作為主鍵鍵值。
關於資料庫主鍵和外來鍵終於弄懂啦
什麼是外來鍵？說明你的表a中的某項a，是引用表b的某列b為什麼要使用外來鍵？rdbms的基本概念，可以維護資料庫的完整。如何來用，涉及到資料庫的定義。唯一約束和主鍵的區別是什麼？唯一性約束 唯一性約束所在的列允許空值，但是主鍵約束的列不允空值。可以把唯一約束放在乙個或者多個列上，但是，唯一性約束所在...
外來鍵及連線查詢
一 外來鍵 外來鍵約束 foreign key 保持資料一致性，完整性 實現一對一，一對多關係 1 父表 參照列的表 和子表 有外來鍵表 2 相同的儲存引擎，且只能為innodb 3 外來鍵列和參照列必須具有相應的資料型別 4 外來鍵列和參照列必須建立索引，如果外來鍵不存在索引，mysql將自動建立...