問題描述

問題解答

外鍵是約束，既然是約束肯定就會增加額外的開銷。例如書中常見的示例，學生選課系統，學生表和課程表，中間肯定會有一個學生課程關聯表。如果添加了外鍵約束，你在刪除某個課程的時候，肯定會先檢查這個課程是不是有學生已經選了，不然你刪除后學生選的那個課程會找不到而引發錯誤。

不明白為什么要反模式，省略外鍵約束能使得數據庫設計更加簡單、靈活，或者執行更加高效，但你還是不得不在其他方面付出相應的代價，必須增加額外的代碼來手動維護引用完整性。本來數據庫一個約束鍵可以解決的，現在還要寫一段代碼去維護。而且手動寫代碼維護判斷，也是一種約束，也會有性能損耗，只不過是在邏輯層面，和數據庫相比不會快到哪去吧。

外鍵必須要用innodb，速度較慢，用myisam速度更快，外鍵可以用關聯查詢解決

外鍵和例如范式這種東西只應該存在于教科書上面。禁止外鍵和反范式才是應該做的。外鍵和查詢效率并沒有聯系。作用僅僅是建立數據的聯系，那么，數據的聯系為何不通過邏輯來約束呢。

有些公司建表不加外鍵

工作以來從沒加過外鍵 :D 依賴多了反而麻煩，性能的話應該沒影響吧，從來沒看見過添加外鍵來提升效率的文檔。 我是菜鳥，別噴我，哈哈，傷不起。路過路過

外健主要是保持數據的完整性和一致性。譬如用戶表和用戶訂單表，如果沒有外健關聯，你是可以插入訂單表的。但是這個訂單表屬于那個用戶，你怎么知道。那這樣的數據就成孤魂野鬼了。有了外健關聯。你在插入的時候必須要求用戶表中有相關用戶才能插入，同里你在刪除用戶表的數據時，如果訂單表有引用的話，你是無法刪除的。這就保證了數據的一致性和完整性。

外鍵約束主要是在數據庫層面上保證數據的一致性，對性能提升沒什么幫助，因為插入和更新數據需要檢查外鍵，理論上性能會有所下降，在oralce中外鍵會增加主從表中主表鎖定的競爭，對性能是負面的影響。

實際的項目，不建議使用外鍵，一方面是降低開發的復雜度（有外鍵的話主從表類的操作必須先操作主表），另外是有外鍵在處理數據的時候非常麻煩。

在應用層面做數據的一致性檢查，本來就是一個正常的功能需求，如學生選課的場景，課程肯定不是輸入的，而是通過下拉或查找等方式從系統中進行選取，就能夠保證是合法的課程ID，因此就不需要靠數據庫的外鍵來檢查了。