[資料庫]資料庫中為什麼不推薦使用外來鍵約束

引言

其實這個話題是老生常談，很多人在工作中確實也不會使用外來鍵。包括在阿里的JAVA規範中也有下面這一條：

【強制】不得使用外來鍵與級聯，一切外來鍵概念必須在應用層解決。 

但是呢，詢問他們原因，大多是這麼回答的：

每次做DELETE 或者UPDATE都必須考慮外來鍵約束，會導致開發的時候很痛苦,測試資料極為不方便。

坦白說，這麼說也是對的。但是呢，不夠全面，所以開一文來詳細說明。

正文

首先我們明確一點，外來鍵約束是一種約束，這個約束的存在，會保證表間資料的關係“始終完整”。因此，外來鍵約束的存在，並非全然沒有優點。比如使用外來鍵，可以：

• 保證資料的完整性和一致性；

• 級聯操作方便；

• 將資料完整性判斷託付給了資料庫完成，減少了程式的程式碼量；

然而，魚和熊掌不可兼得。外來鍵是能夠保證資料的完整性，但是會給系統帶來很多缺陷。正是因為這些缺陷，才導致我們不推薦使用外來鍵，具體如下：

效能問題

假設一張表名為user_tb。那麼這張表裡有兩個外來鍵欄位，指向兩張表。那麼，每次往user_tb表裡插入資料，就必須往兩個外來鍵對應的表裡查詢是否有對應資料。如果交由程式控制，這種查詢過程就可以控制在我們手裡，可以省略一些不必要的查詢過程。但是如果由資料庫控制，則是必須要去這兩張表裡判斷。

併發問題

在使用外來鍵的情況下，每次修改資料都需要去另外一個表檢查資料,需要獲取額外的鎖。若是在高併發大流量事務場景，使用外來鍵更容易造成死鎖。

擴充套件性問題

這裡主要是分為兩點：

• 做平臺遷移方便，比如你從Mysql遷移到Oracle，像觸發器、外來鍵這種東西，都可以利用框架本身的特性來實現，而不用依賴於資料庫本身的特性，做遷移更加方便。

• 分庫分表方便，在水平拆分和分庫的情況下，外來鍵是無法生效的。將資料間關係的維護，放入應用程式中，為將來的分庫分表省去很多的麻煩。

技術問題

使用外來鍵，其實將應用程式應該執行的判斷邏輯轉移到了資料庫上。那麼這意味著一點，資料庫的效能開銷變大了，那麼這就對DBA的要求就更高了。很多中小型公司由於資金問題，並沒有聘用專業的DBA，因此他們會選擇不用外來鍵，降低資料庫的消耗。
相反的，如果該約束邏輯在應用程式中，發現應用伺服器效能不夠，可以加機器，做水平擴充套件。如果是在資料庫伺服器上，資料庫伺服器會成為效能瓶頸，做水平擴充套件比較困難。