其實這個話題是老生常談，很多人在工作中確實也不會使用外鍵。包括在阿里的JAVA規範中也有下面這一條：
【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。
但是呢，詢問他們原因，大多是這麼回答的：
每次做DELETE 或者UPDATE都必須考慮外鍵約束，會導致開發的時候很痛苦,測試數據極爲不方便。
坦白說，這麼說也是對的。但是呢，不夠全面，所以開一文來詳細說明。
正文
首先我們明確一點，外鍵約束是一種約束，這個約束的存在，會保證表間數據的關係“始終完整”。因此，外鍵約束的存在，並非全然沒有優點。比如使用外鍵，可以：
-
保證數據的完整性和一致性；
-
級聯操作方便；
-
將數據完整性判斷託付給了數據庫完成，減少了程序的代碼量；
然而，魚和熊掌不可兼得。外鍵是能夠保證數據的完整性，但是會給系統帶來很多缺陷。正是因爲這些缺陷，才導致我們不推薦使用外鍵，具體如下：
性能問題
假設一張表名爲user_tb。那麼這張表裏有兩個外鍵字段，指向兩張表。那麼，每次往user_tb表裏插入數據，就必須往兩個外鍵對應的表裏查詢是否有對應數據。如果交由程序控制，這種查詢過程就可以控制在我們手裏，可以省略一些不必要的查詢過程。但是如果由數據庫控制，則是必須要去這兩張表裏判斷。
併發問題
在使用外鍵的情況下，每次修改數據都需要去另外一個表檢查數據,需要獲取額外的鎖。若是在高併發大流量事務場景，使用外鍵更容易造成死鎖。
擴展性問題
這裏主要是分爲兩點：
-
做平臺遷移方便，比如你從
Mysql遷移到Oracle，像觸發器、外鍵這種東西，都可以利用框架本身的特性來實現，而不用依賴於數據庫本身的特性，做遷移更加方便。 -
分庫分表方便，在水平拆分和分庫的情況下，外鍵是無法生效的。將數據間關係的維護，放入應用程序中，爲將來的分庫分表省去很多的麻煩。
技術問題
使用外鍵，其實將應用程序應該執行的判斷邏輯轉移到了數據庫上。那麼這意味着一點，數據庫的性能開銷變大了，那麼這就對DBA的要求就更高了。很多中小型公司由於資金問題，並沒有聘用專業的DBA，因此他們會選擇不用外鍵，降低數據庫的消耗。
相反的，如果該約束邏輯在應用程序中，發現應用服務器性能不夠，可以加機器，做水平擴展。如果是在數據庫服務器上，數據庫服務器會成爲性能瓶頸，做水平擴展比較困難。