禁用外鍵約束是什么

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

為什么禁用外鍵約束

首先，假設我們用了數據庫約束外鍵，每次做 DELETE 或者 UPDATE 都必須考慮外鍵約束，會導致開發的時候很痛苦,測試數據極為不方便。

如果測試或者開發時我們需要刪除某個表的數據，如果此時使用了外鍵約束與此表有十幾個關聯，那豈不是要炸毛了。當然這是使用層面帶來的麻煩。

當然使用外鍵約束也有優點，保證數據的完整性和一致性、級聯操作方便、數據一致性交給數據庫、代碼量小。任何事情都會有利有弊。

接下來我們通過案例進行講解

案例講解

這是一個很常見的訂單與訂單明細表，訂單表的主鍵與訂單明細表的訂單 Id 存在外鍵約束關系

數據庫層面外鍵約束維度

1 . 性能問題

額外的數據一致性校驗查詢，當在訂單明細表進行數據插入操作時，會檢查訂單表里是否存在對于的外鍵約束數據

2 . 并發問題

外界約束會啟用行級鎖，主表寫入時會進入阻塞，什么意思呢？

當用戶買了十幾樣商品，在對于的訂單明細表就會有十幾行數據，再每次插入的時候，都會去檢查訂單表里是否存在訂單 ID ，這是正常的流程。

但是，如果在并發環境下，訂單明細表向訂單表檢查外鍵約束關系的時候，會在訂單表開啟一個共享鎖（讀鎖）。

如果此時甭管什么原因，此時有個請求需要修改訂單表的訂單 ID ，此時訂單表就會開啟一個排它鎖（寫鎖）。那么此時訂單明細表就會進入一個阻塞的狀態，就行進行一個線程的擠壓，進而引發系統崩潰。

3 . 級聯刪除問題

多層級聯刪除會讓數據變得不可控，觸發器也嚴格被禁用，什么意思呢？

如果此時我們想刪除訂單類型，應為訂單表與訂單類型表存在外鍵約束關系，那么對于的訂單表里的此類型的訂單都將會被刪除，訂單明細表的明細也將會刪除。如果存在更多的外鍵約束關系，則會刪除一連串的數據，此時就會變得不可控。

這些操作都是在數據庫層面發生的，都是無法追溯的，是一件很麻煩的事。所以在實際開發中數據庫層面的外鍵約束是嚴令禁止的。

4 . 數據耦合

數據庫層面數據關系產生耦合，數據遷移維護困難，什么意思呢？

如果某一天，訂單明細表的數據量過大，基于 MySQL 本身的性能應用已經不足以支持相對應的業務需求。此時計劃將訂單明細數據遷移到 HBASE 這樣的大數據數據庫進行存儲。

那么此時是不是需要將原有的主外鍵約束關系給去掉，之后又如何保證數據的一致性問題呢，此時只能通過程序層面進行約束，這是不是又回到了應用層面。

在實際的項目經驗過程中，隨著業務發展，有些業務數據就會非常大，而應為關系型數據庫本身的性能問題，此時有些數據就會進行一些遷移，這是非常常見的，而此時就需要在應用層面確保數據的一致性，所以也就是有些公司為什么不推薦使用外鍵約束的原因。

總結

以上是生活随笔為你收集整理的详谈为什么互联网公司禁用外键约束的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。