從 MySQL 物理外來鍵開始的思考

首先貼一下知乎上的問題和回答

為什麼很多mysq課程不推薦用物理外來鍵

之前是由於有師弟跟我討論這個問題，然後我是順便搜了下知乎把想法也都寫下，現在把他放回部落格，然後進行了一下細化，依然是just a door系列，依然是為了更前面的**一些問題，本期topic是物理外來鍵~let』s start with mysql

first of all，什麼是物理外來鍵，好吧雖然基礎，但是我們不能跑偏，所以囉嗦的蟲子還是喜歡把概念鏈結給貼上，維基百科更詳細，不過這個逼就不裝了，留給你們吧

foreign-key(w3school)

using foreign key constraints(mysql官網)

原文：用外來鍵的好處我就不多說了，既然是關係型資料庫，外來鍵的約束為我們保證了資料主從關係和產生的先後關係，級聯操作為我們的update和delete帶來了不少方便。但成本是有的，你要權衡你是不是想付出這些代價。成本參考以下幾點：

一、外來鍵的效能問題

我剛寫了一些，然後發現有人寫的更好而且簡潔，就引用吧：@mysqlops

為何說外來鍵有效能問題：

1.資料庫需要維護外來鍵的內部管理；

2.外來鍵等於把資料的一致性事務實現，全部交給資料庫伺服器完成；

3.有了外來鍵，當做一些涉及外來鍵字段的增，刪，更新操作之後，需要觸發相關操作去檢查，而不得不消耗資源；

4.外來鍵還會因為需要請求對其他表內部加鎖而容易出現死鎖情況；

這裡我覺得這個可以拿出來細說，裡面提到的點，對資料庫伺服器的消耗成本還是蠻高的，畢竟關係型db不知道你想幹嘛，他老怕你出錯，老幫你檢查，數量級一上去，這個消耗就跟著上去。

二、mysql的外來鍵設計問題（對sql標準的背離）

雖然很多人都不推薦你在關係型資料庫使用外來鍵。但你更多聽到的是mysql的，而不是sqlserver或者其他。比較公認的是，他的外來鍵設計得的確不是很好，限制多功能不強大等。（同樣的，討論是不是該用儲存過程也存在這種思考）

這裡貼上一些從看到的，比較嚴重的問題。

關於對sql標準的背離（這裡只貼其中乙個點）

預設的行為應被延遲檢查（即約束僅在整個sql語句被處理之後才被檢查）

類似一般的mysql，在乙個插入，刪除或更新許多行的sql語句內，innodb逐行檢查unique和foreign key約束。

直到innodb實現延遲的約束檢查之前，一些事情是不可能的，比如刪除乙個通過外來鍵參考到自身的記錄。

三、不使用外來鍵我們也有好的解決方案外來鍵是個好東西，他為選擇了關係型資料庫的我們做了約束和級聯做了保障。但不使用物理外來鍵的我們也有方案去實現我們的邏輯外來鍵，並保證他正確執行。

資料庫上的乙個策略：可以選擇大多數情況下我們只更新不刪除，也就是邏輯刪，不再使用的歷史資料定期歸檔來減少壓力。

**上的各種設計和限制：對錶範圍的操作許可權，開啟事務去處理邏輯，有需要進行非同步操作來提高效能的我們設計補償機制去彌補，等等。

四、外來鍵對拓展性的限制和影響

計畫趕不上變化，外來鍵的主從關係是定的，然後你會因為這個做很多事情，但是萬一哪天主鍵所在表就見鬼去了呢？萬一哪天你發現外來鍵表不是非得跟人家的主鍵掛上關係呢？就我經歷過的來看，這種情況並不少見，尤其是資料庫設計者水平不夠高的情況下。

另乙個看法比較主觀，就是你讓資料庫去幫你管外來鍵了，你平時寫程式的時候就真的很思路清晰嗎？因為某些原因（比如你想要的關聯式資料庫不支援，mysql經常），有些地方你就不能設計外來鍵了，到時候一有級聯更新的需要時，一部分你靠物理外來鍵，一部分你還得靠自己，我覺得還不如全靠**邏輯去保證。即使你對業務理解深刻，對外鍵也掌握的透徹，你也不太希望老是你管一部分他管一部分吧？

五、反對的聲音

最後再來說說一些堅持用外來鍵的思考

有人問：原本在物理外來鍵的開銷，在程式上不也有開銷嗎？的確，但是這樣我們對優化效能的方式也靈活了，剛剛說的非同步處理就是一種。視具體情況而定，如果設計的好，有時候某些無用資料你不是非得立刻刪除他，甚至不是非得刪除他。

對於關係型資料庫正確性》效能的說法，如果邏輯複雜到一定程度，物理外來鍵一定能給你提供正確性嗎？這個可以討論討論。

最後，我這裡送個東西 mysql 5.1參考手冊

從 MySQL 物理外來鍵開始的思考

mysql外來鍵的應用 MySQL外來鍵應用

mysql 所有外來鍵 mysql中的外來鍵

MySQL 外來鍵及外來鍵的使用

從 MySQL 物理外來鍵開始的思考

mysql外來鍵的應用 MySQL外來鍵應用

mysql 所有外來鍵 mysql中的外來鍵

MySQL 外來鍵及外來鍵的使用

相關推薦