闭关修行中......
外鍵是約束，既然是約束肯定就會增加額外的開銷。例如書中常見的範例，學生選課系統，學生表和課程表，中間一定會有一個學生課程關聯表。如果新增了外鍵約束，你在刪除某個課程的時候，一定會先檢查這個課程是不是有學生已經選了，不然你刪除後學生選的那個課程會找不到而引發錯誤。
不明白為什麼要反模式，省略外鍵約束能使得資料庫設計更加簡單、靈活，或者執行更加高效，但你還是不得不在其他方面付出相應的代價，必須增加額外的程式碼來手動維護引用完整性。本來資料庫一個約束鍵可以解決的，現在還要寫一段程式碼去維護。而且手動寫程式碼維護判斷，也是一種約束，也會有效能損耗，只不過是在邏輯層面，和資料庫相比不會快到哪去吧。
外鍵必須用innodb，速度較慢，用myisam速度更快，外鍵可以用關聯查詢解決
外鍵和例如範式這種東西只應該存在於教科書上面。禁止外鍵和反範式才是應該做的。外鍵和查詢效率並沒有連結。作用只是建立資料的聯繫，那麼，為何資料的聯繫為何不透過邏輯來約束呢。
有些公司建表不加外鍵
工作以來從來沒加過外鍵 :D 依賴多了反而麻煩，性能的話應該沒影響吧，從來沒看見過添加外鍵來提升效率的文檔。 我是菜鳥，別噴我，哈哈，傷不起。路過路過
外健主要是保持資料的完整性和一致性。譬如用戶表和用戶訂單表，如果沒有外健關聯，你是可以插入訂單表的。但是這個訂單表屬於那個用戶，你怎麼知道。那這樣的數據就變成孤魂野鬼了。有了外健關聯。你在插入的時候必須要求用戶表中有相關用戶才能插入，同里你在刪除用戶表的資料時，如果訂單表有引用的話，你是無法刪除的。這就保證了資料的一致性和完整性。
外鍵約束主要是在資料庫層面保證資料的一致性，對效能提升沒什麼幫助，因為插入和更新資料需要檢查外鍵，理論上效能會有所下降，在oralce中外鍵會增加主從表中主表鎖定的競爭，對效能是負面的影響。
實際的項目，不建議使用外鍵，一方面是降低開發的複雜度（有外鍵的話主從表類的操作必須先操作主表），另外是有外鍵在處理數據的時候非常麻煩。
在應用層面做資料的一致性檢查，本來就是一個正常的功能需求，如學生選課的場景，課程肯定不是輸入的，而是透過下拉或查找等方式從系統中進行選取，就能夠保證是合法的課程ID，因此就不需要靠資料庫的外鍵來檢查了。
外鍵是約束，既然是約束肯定就會增加額外的開銷。例如書中常見的範例，學生選課系統，學生表和課程表，中間一定會有一個學生課程關聯表。如果新增了外鍵約束，你在刪除某個課程的時候，一定會先檢查這個課程是不是有學生已經選了，不然你刪除後學生選的那個課程會找不到而引發錯誤。
不明白為什麼要反模式，省略外鍵約束能使得資料庫設計更加簡單、靈活，或者執行更加高效，但你還是不得不在其他方面付出相應的代價，必須增加額外的程式碼來手動維護引用完整性。本來資料庫一個約束鍵可以解決的，現在還要寫一段程式碼去維護。而且手動寫程式碼維護判斷，也是一種約束，也會有效能損耗，只不過是在邏輯層面，和資料庫相比不會快到哪去吧。
外鍵必須用innodb，速度較慢，用myisam速度更快，外鍵可以用關聯查詢解決
外鍵和例如範式這種東西只應該存在於教科書上面。禁止外鍵和反範式才是應該做的。外鍵和查詢效率並沒有連結。作用只是建立資料的聯繫，那麼，為何資料的聯繫為何不透過邏輯來約束呢。
有些公司建表不加外鍵
工作以來從來沒加過外鍵 :D 依賴多了反而麻煩，性能的話應該沒影響吧，從來沒看見過添加外鍵來提升效率的文檔。 我是菜鳥，別噴我，哈哈，傷不起。路過路過
外健主要是保持資料的完整性和一致性。譬如用戶表和用戶訂單表，如果沒有外健關聯，你是可以插入訂單表的。但是這個訂單表屬於那個用戶，你怎麼知道。那這樣的數據就變成孤魂野鬼了。有了外健關聯。你在插入的時候必須要求用戶表中有相關用戶才能插入，同里你在刪除用戶表的資料時，如果訂單表有引用的話，你是無法刪除的。這就保證了資料的一致性和完整性。
外鍵約束主要是在資料庫層面保證資料的一致性，對效能提升沒什麼幫助，因為插入和更新資料需要檢查外鍵，理論上效能會有所下降，在oralce中外鍵會增加主從表中主表鎖定的競爭，對效能是負面的影響。
實際的項目，不建議使用外鍵，一方面是降低開發的複雜度（有外鍵的話主從表類的操作必須先操作主表），另外是有外鍵在處理數據的時候非常麻煩。
在應用層面做資料的一致性檢查，本來就是一個正常的功能需求，如學生選課的場景，課程肯定不是輸入的，而是透過下拉或查找等方式從系統中進行選取，就能夠保證是合法的課程ID，因此就不需要靠資料庫的外鍵來檢查了。