問題描述

問題解答

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

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

外鍵必須要用innodb，速度較慢，用myisam速度更快，外鍵可以用關(guān)聯(lián)查詢解決

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

有些公司建表不加外鍵

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

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

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

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

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