外鍵約束是為了保持子表與父表的數據一致，用于在兩個表之間建立關系，需要指定引用主表的哪一列。InnoDB是MySQL內置存儲引擎中唯一一個支持外鍵的。InnoDB會強制外鍵使用索引。事實上，我們每次做DELETE 或者UPDATE都必須考慮外鍵約束，會導致開發的時候很痛苦,測試數據極為不方便。本文我們就來探討一下MySQL外鍵約束的問題。

首先我們明確一點，外鍵約束是一種約束，這個約束的存在，會保證表間數據的關系“始終完整”。因此，外鍵約束的存在，并非全然沒有優點。比如使用外鍵，可以保證數據的完整性和一致性級聯操作方便將數據完整性判斷托付給了數據庫完成，減少了程序的代碼量然而，魚和熊掌不可兼得。外鍵是能夠保證數據的完整性，但是會給系統帶來很多缺陷。正是因為這些缺陷和問題，才導致我們不推薦使用外鍵，MySQL外鍵約束帶來的問題具體如下4個，我們來詳細學習一下：

1.性能問題

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

2.并發問題

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

3.擴展性問題

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

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

4.技術問題

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

除此之外，使用mysql外鍵約束是有成本的，因為每次修改數據都要在另外一個表中執行查詢操作，雖然如上面所說，外鍵字段有索引，但還是會帶來額外的開銷。這些開銷跟外鍵上的索引有很大關系，一般外鍵列的選擇性很低，就會產生一個非常大但是選擇性低的索引，那么這個索引除了做外鍵限制，沒有其他的用處，維護這樣的索引顯然不是高效的做法。因此，我們在日常使用MySQL的過程中，并不推薦使用外鍵約束。想要深入學習MySQL的各種機制，可以觀看本站的MySQL教程，體驗不一樣的學習之旅。