為什麼很多mysql課程不推薦用物理外鍵？

回複內容：

因為mysql資料庫設計得不好，用資料庫的外鍵有問題。以及，近年來互連網的發展，弱化資料庫，可以容忍錯誤資料錯誤也成為潮流。犧牲正確性換取效率，成為潮流。DBA的水平越來也差也成為事實。

別說mysql了，其他資料庫也都不用外鍵了。犧牲掉資料的正確性被認為是沒有任何問題的。哪怕銀行的系統也是一樣。至於業務上如何保證關鍵資料（錢）是對的？好幾個系統互相對賬唄。

錯了，修複資料嘛。只要錯得不離譜就行。用外鍵也不能保證不出業務錯誤。很多時候外鍵的串聯更新或者刪除造成了效能災難。只能級聯禁止，這樣造成了開發效率的下降。沒有開發效率，如何有時間修複bug和最佳化系統呢？

外鍵會和觸發器一樣變成小眾和適用情境及其少的遺留技術。其實不光是mysql，從DBA的角度出發，我也不建議在oracle裡使用外鍵。
外鍵的效果完全可以通過商務邏輯來保證，但是它帶來的一系列效能問題卻很難有辦法解決。看你要在哪一層面維護模型完整性。我們暫時也沒有用到。但是不應該一概而論，簡單的說外鍵沒有用。使用外鍵的目的是保證資料的完整性，但是這樣會帶來額外的效能上的開銷。替代的做法是可以在應用程式中完成這一步，並且可以通過非同步處理增加效率。其次外鍵在水平分表和分庫的情況下就無法使用了。外健開銷較大，不利於維護，而且在商務邏輯中維護就綽綽有餘了。數量級不夠沒有sharding的系統，最好還是用外鍵約束來保護資料，你不能指望程式猿寫的代碼都是高品質的資料訪問。
大資料量的分布式系統最好別用，拆表拆到死，但也要用別的辦法保證資料完整性才好。

作為新項目的話，個人認為是一定要用的。因為項目迭代的時候，其他代碼大不了推了重做就好，資料要是亂了，那真就是回天乏力了。

