參考：<br>
https://blog.csdn.net/bingqingsuimeng/article/details/51595560
https://blog.csdn.net/zhouziyu2011/article/details/69788073
https://blog.csdn.net/qq_23473123/article/details/79273066
https://blog.csdn.net/tiansheng1225/article/details/77987988
https://blog.csdn.net/xiaobingtao/article/details/9698891

目錄

1、主鍵、外鍵、索引定義

2、為什么定義主鍵、外鍵

3、主鍵和外鍵的關系

4、數據庫中主鍵和外鍵的設計原則

5、數據庫主鍵選取策略/數據庫主鍵的生成策略

6、數據庫外鍵的使用和原則

7、應該創建索引的列的特點

8、不應該創建索引的列的特點

9、可以在數據庫設計器中創建三種索引

10、索引的優缺點

11、主鍵和外鍵以及索引的區別

12、數據庫該不該使用外鍵

13、總結建議

1、主鍵、外鍵、索引定義

對于主/外鍵/索引來說，在一些開發團隊中被認為是處理數據庫關系的利器，也被某些開發團隊認為是處理某些具體業務的魔鬼；

主鍵：

定義：關系型數據庫中的一條記錄中有若干個屬性，若其中某一個屬性組(注意是組)能唯一標識一條記錄，該屬性組就可以成為一個主鍵；

特征：主鍵不能重復，且只能有一個，也不允許為空。

作用：定義主鍵主要是為了維護關系數據庫的完整性。

外鍵：

外鍵用于與另一張表的關聯，是能確定另一張表記錄的字段。

特征：外鍵是另一個表的主鍵，可以重復，可以有多個，也可以是空值。

作用：定義外鍵主要是為了保持數據的一致性。

另一說法：

保持數據一致性，完整性，主要目的是控制存儲在外鍵表中的數據。 使兩張表形成關聯，外鍵只能引用外表中的列的值

例如：
a b 兩個表
a表中存有客戶號，客戶名稱
b表中存有每個客戶的訂單

有了外鍵后
你只能在確信b 表中沒有客戶x的訂單后，才可以在a表中刪除客戶x

索引：

索引是對表中一個或多個列的值進行排序的結構。

2、為什么定義主鍵、外鍵

定義主鍵和外鍵主要是為了維護關系數據庫的完整性:

1.主鍵是能確定一條記錄的唯一標識

2.外鍵用于與另一張表的關聯。是能確定另一張表記錄的字段，用于保持數據的一致性。

3、主鍵和外鍵的關系

外鍵是另一個表的主鍵，主鍵是可以被外鍵有效引用的對象。若A表中的一個字段，是B表的主鍵，則它可以是A表的外鍵。

4、數據庫中主鍵和外鍵的設計原則

主鍵和外鍵是把多個表組織為一個有效的關系數據庫的粘合劑。主鍵和外鍵的設計對物理數據庫的性能和可用性都有著決定性的影響。

必須將數據庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的數據庫用于了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。

主鍵：關系數據庫依賴于主鍵---它是數據庫物理模式的基石。

主鍵在物理層面上只有兩個用途：

1. 惟一地標識一行。

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

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

1. 主鍵應當是對用戶沒有意義的。如果用戶看到了一個表示多對多關系的連接表中的數據，并抱怨它沒有什么用處，那就證明它的主鍵設計地很好。

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

注：使用復合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯誤的。

一是主鍵應當具有實際意義;

錯誤原因：讓主鍵具有意義只不過是給人為地破壞數據庫提供了方便。

二是利用這種方法可以在描述多對多關系的連接表中使用兩個外部鍵來作為主鍵，我也反對這種做法；

反對理由：復合主鍵常常導致不良的外鍵，即當連接表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然，這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠后的從表，其主鍵將會包含越多的列了。

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

注：這項原則對于那些經常需要在數據轉換或多數據庫合并時進行數據整理的數據并不適用。

4. 主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等。

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

5、數據庫主鍵選取策略/數據庫主鍵的生成策略

常見的數據庫主鍵選取方式有：

（1）自動增長字段

（2）手動增長字段

（3）UniqueIdentifier

（4）“COMB（Combine）”類型

參考：

SQL SERVER數據庫主鍵選取方式: https://blog.csdn.net/sas5215/article/details/7027367

Oracle數據庫主鍵的生成策略: http://www.169it.com/tech-oracle/article-12466421275288522018.html

6、數據庫外鍵的使用和原則

建立外鍵的前提： 本表的列必須與外鍵類型相同(外鍵必須是外表主鍵)。

指定主鍵關鍵字： foreign key(列名)

引用外鍵關鍵字： references <外鍵表名>(外鍵列名)

事件觸發限制: on delete和on update , 可設參數cascade(跟隨外鍵改動), restrict(限制外表中的外鍵改動),set Null(設空值）,set Default（設默認值）,[默認]no action

7、應該創建索引的列的特點

①　在經常需要搜索的列上創建索引，可以加快搜索的速度；

②　在作為主鍵的列上創建索引，強制該列的唯一性；

③　在經常用在連接的列上創建索引，主要是一些外鍵，可以加快連接的速度；

④　在經常需要根據范圍進行搜索的列上創建索引，因為索引已經排序，其指定的范圍是連續的；在經常需要排序的列上創建索引，因為索引已經排序，可以利用索引的排序加快查詢；

⑤　在經常使用在WHERE子句中的列上創建索引，加快條件的判斷速度。

8、不應該創建索引的列的特點

①　在查詢中很少使用的列上不應該創建索引，因為這些列很少使用到，因此有索引或無索引，并不能提高查詢速度，相反由于增加了索引，反而降低了系統維護速度，增大了空間需求；

②　在只有很少數據值的列上不應該創建索引，很少數據值的列如性別等，在查詢的結果中，結果集的數據行占了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大，增加索引，并不能明顯加快檢索速度；

③　當修改性能遠遠大于檢索性能時，不應該創建索引，因為改性能和檢索性能是互相矛盾的，當增加索引時，會提高檢索性能，但會降低修改性能，當減少索引時，會提高修改性能，但會降低檢索性能。因此，當修改性能遠大于檢索性能時，不應該創建索引。

9、可以在數據庫設計器中創建三種索引

①　唯一索引：

不允許其中任何兩行具有相同索引值的索引。

②　主鍵索引：

表的某一列或列組合，其值唯一標識表中的每一行，該列或列組合稱為表的主鍵。為表定義主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。

③　聚集索引：

聚集索引：聚集索引表示表中存儲的數據按照索引的順序存儲。由于聚集索引規定數據在表中的物理存儲順序，因此一個表只能包含一個聚集索引。

聚集索引實例：字典默認按字母順序排序，如知道某個字的讀音可根據字母順序快速定位。

非聚集索引：非聚集索引表示數據存儲在一個地方，索引存儲在另一個地方，索引帶有指針指向數據的存儲位置，需要查詢兩個地方才能查找到數據。一個表可以包含多個非聚集索引，可以為查找數據時常用的每個列創建一個非聚集索引。

非聚集索引實例：如需查詢某個生僻字，則需按字典前面的索引，如按偏旁進行定位，找到該字對應的頁數，再打開對應頁數找到該字。

與非聚集索引相比，聚集索引通常提供更快的數據訪問速度，但對數據更新影響較大。

10、索引的優缺點

優點：

加快對數據的檢索。

缺點：

①　減慢數據錄入的速度；

②　增加了數據庫的尺寸大小。

11、主鍵和外鍵以及索引的區別

12、數據庫該不該使用外鍵

數據庫該不該使用外鍵背景

背景一、

在自己2年（2017~2019）的java web企業級應用開發的工作經驗中，在項目中所使用的Oracle數據庫幾乎未用到過外鍵，不使用外鍵的兩個原因：

（1）項目較小且業務場景無必要給數據庫表建外鍵；

（2）如果建了外鍵，數據庫設計變冗余，顯的為了數據庫設計而設計（估計是自己所涉及企業級應用功能相對簡單，大部分數據業務場景全清全入）

背景二、

以前的意識里都是需要建立外鍵，外鍵能起到約束作用，能保證數據的完整性和一致性，比如如果沒有外鍵約束，你自己程序控制又不到位把基本信息都刪除了，詳情卻存在，人的基本信息不存在了，工資信息里卻存在這個人，想要找這個人究竟是誰都找不到。

今天看到原來的外鍵都被去掉了，問了下組長，結果回答就兩個字“效率”，雖然感覺很詫異，但是畢竟人家比我有經驗并沒有去爭論，下面將站在兩個對立面去贊成和反對建立外鍵。

From https://blog.csdn.net/qq_23473123/article/details/79273066

背景三、

對于主/外鍵/索引來說，在一些開發團隊中被認為是處理數據庫關系的利器，也被某些開發團隊認為是處理某些具體業務的魔鬼；

共同觀點：

主鍵和索引是不可少的，不僅可以優化數據檢索速度，開發人員還省其它的工作；

矛盾焦點：數據庫設計是否需要外鍵；

這里有兩個問題：
一個是如何保證數據庫數據的完整性和一致性；
二是第一條對性能的影響。

正方觀點：

1，由數據庫自身保證數據一致性，完整性，更可靠，因為程序很難100％保證數據的完整性，而用外鍵即使在數據庫服務器當機或者出現其他問題的時候，也能夠最大限度的保證數據的一致性和完整性。

eg：數據庫和應用是一對多的關系，Ａ應用會維護他那部分數據的完整性，系統一變大時，增加了Ｂ應用，
Ａ和Ｂ兩個應用也許是不同的開發團隊來做的。
他們如何協調保證數據的完整性，而且一年以后如果又增加了C應用呢？

2，有主外鍵的數據庫設計可以增加ER圖的可讀性，這點在數據庫設計時非常重要。

3，外鍵在一定程度上說明的業務邏輯，會使設計周到具體全面。

反方觀點：

1，可以用觸發器或應用程序保證數據的完整性；

2，過分強調或者說使用主鍵／外鍵會平添開發難度，導致表過多等問題；

3，不用外鍵時數據管理簡單，操作方便，性能高（導入導出等操作，在insert,update,delete數據的時候更快）

eg:在海量的數據庫中想都不要去想外鍵，試想，一個程序每天要insert數百萬條記錄，當存在外鍵約束的時候，
每次要去掃描此記錄是否合格，一般還不止一個字段有外鍵，這樣掃描的數量是成級數的增長！
我的一個程序入庫在3個小時做完，如果加上外鍵，需要28個小時！

建與不建外鍵

注意這里說的建與不建不是說不要外鍵，盡可能把表弄成一張表，而是說人為控制還是數據庫使用本身外鍵約束。

建

利用數據庫保證數據庫完整性和一致性；自己用程序控制怕有疏忽，外鍵多起來麻煩；同一個數據庫可能給不同應用用，但是開發數據庫的人并不是開發應用的人，開發應用的人對數據庫不夠了解，就算開發數據庫的人去開發應用時間長也會忘記；

不建

導數據入庫要有先后順序，而且也會檢查外鍵是否存在，十分消耗時間；刪除數據也是；

還有就是可能數據建立的約束可能效率不夠高，想自己建立高效的約束。

不建外鍵的其他參考：

使用外鍵有利于維持數據完整性和一致性，但是對于開發來說是非常不利的。  
每次做DELETE 或者UPDATE都必須考慮外鍵約束，會導致開發的時候很痛苦，而且需要更為復雜的錯誤捕獲機制。 
做數據處理時會受到很多的束縛，有些地方本來就可以允許有部分冗余，但是由于設計了外鍵約束，只能放棄。 
出現BUG的時候追蹤很麻煩。   
總的來說，自己來掌握數據總比別人去掌握要方便，由程序控制一致性和唯一性。

From https://blog.csdn.net/xiaobingtao/article/details/9698891

13、總結建議

總結建議一

我自己覺得完整性和一致性肯定是需要保證的，不然會出問題，也會影響效率，需要看你項目又多大。

小型項目就使用數據庫本身的，效率追求不高，也沒必要花時間自己建立約束，時間代價比較大。

較大型項目可能數據約束本身效率不夠好，滿足不了大項目對效率的要求，又有人力物力去支持建立自己的高效約束。

還有較大項目初期，想早點上線，效率要求沒有那么大，沒時間去建立高效率約束，那么就用數據庫本身的約束，項目初期要求穩定一些比較好。

總結建議二

1，在大型系統中（性能要求不高，安全要求高），使用外鍵；在大型系統中（性能要求高，安全自己控制），不用外鍵；小系統隨便，最好用外鍵。

2，用外鍵要適當，不能過分追求

3，不用外鍵而用程序控制數據一致性和完整性時，應該寫一層來保證，然后個個應用通過這個層來訪問數據庫。