本科學習資料庫的時候，書上明確的寫了對於多對多關係必須要建立外來鍵，可是最近在跟師兄做乙個b/s架構的專案，發現所設計的資料庫表雖然是多對多關係但並沒有要求外來鍵，查了一下之後才發現目前的大型系統中（尤其是網際網路的大型專案）不會有外來鍵這種東西，在這裡總結一下以供今後學習。
設計資料庫時是否採用外來鍵取決於業務應用場景，以及開發成本，也就是說對於這個問題並沒有絕對的答案。
應用場景的比較 網際網路行業應用不推薦使用外來鍵： 使用者量大，併發度高，為此資料庫伺服器很容易成為效能瓶頸，尤其受io能力限制，且不能輕易地水平擴充套件；若是把資料一致性的控制放到事務中，也即讓應用伺服器承擔此部分的壓力，而引用伺服器一般都是可以做到輕鬆地水平的伸縮；總結：傳統行業（軟體使用人數可控）的可以使用外來鍵。
外來鍵的效能問題
1.資料庫需要維護外來鍵的內部管理；
2.外來鍵等於把資料的一致性事務實現，全部交給資料庫伺服器完成；
3.有了外來鍵，當做一些涉及外來鍵字段的增，刪，更新操作之後，需要觸發相關操作去檢查，而不得不消耗資源；
4.外來鍵還會因為需要請求對其他表內部加鎖而容易出現死鎖情況；
歷史背景：
資料庫的諸多設計，帳號，許可權，約束，觸發器，都是為 c/s 結構設計的，是以 c 端不可信做為假設前提的。b/s 模式安全邊界前移到 web 服務層，應用與資料庫之間是可信的，應用自行完成這些功能更加靈活。
外來鍵約束定義在具有父子關係的子表中，外來鍵約束使得子表中的列對應父表的主鍵列，用以維護資料庫的完整性。不過出於效能和後期的業務系統的擴充套件的考慮，很多時候，外來鍵約束僅出現在資料庫的設計中，實際會放在業務程式中進行處理。在大型網際網路專案中不使用外來鍵，是為了系統的效能，但這並不代表沒有實現實現表與關聯表之間的資料一致性和更新，只不過是在業務層對此做了限制，確保由service到dao再到service都是符合資料庫規範的，與使用外來鍵的作用是相同的，但這樣做可以進一步提公升系統效能。
在本科學習資料庫課程的時候，老師確實強調要寫外來鍵，因為只是從資料庫課程本身出發來進行資料庫設計時需要，並沒有從工程巨集觀角度去考量，在實際開發中情況往往是除了主鍵和非空約束外，其他的都不要，主要通過程式來控制外來鍵關聯！因此，實踐和理論還是有差別的，但有一點卻是不變的，那就是無論理論還是實踐都是用來為實際需求服務的，也就是說「怎麼好怎麼來，要因時制宜，靈活變通。」
約束是資料庫用來確保資料滿足業務規則的手段，不過在真正的企業開發中，除了主鍵約束這類具有強需求的約束，像外來鍵約束，檢查約束更多時候僅僅出現在資料庫設計階段，真實環境卻很少應用，更多是放到程式邏輯中去進行處理。這也比較容易理解，約束會一定程度上降低資料庫效能，有些規則直接在程式邏輯中處理就可以了，同時，也有可能在面對業務變更或是系統擴充套件時，資料庫約束會使得處理不夠方便。不過在我看來，資料庫約束是保證資料準確性的最後一道防線，對於設計合理的系統，處於效能考慮資料庫約束自然可有可無；不過若是面對關聯關係較為複雜的系統，且對系統而言，資料的準確性完整性要高於效能要求，那麼這些約束還是有必要的（否則，就會出現各種相對業務規則來說莫名其妙的髒資料，本人可是深有體會的。。）。總之，對於約束的選擇無所謂合不合理，需要根據業務系統對於準確性和效能要求的側重度來決定。
MySql資料庫外來鍵關聯
設定外來鍵關聯是可以設定在刪除時和在更新時的操作，其中有三個比較重要的。1 層疊 級聯 cache 2 設為null set null 3 無動作 no action 1 層疊，當主表刪除一條記錄，那麼從表對應的引用了被刪除的記錄的主鍵作為外來鍵的記錄將會級聯刪除。更新時候也一樣。2 設為null，...
資料庫外來鍵， 用還是不用？
對於主 外來鍵 索引來說，在一些開發團隊中被認為是處理資料庫關係的利器，也被某些開發團隊認為是處理某些具體業務的魔鬼，您的觀點呢？在實際應用中您會採取哪種方式？主鍵和索引是不可少的，不僅可以優化資料檢索速度，開發人員還省不其它的工作,矛盾焦點 資料庫設計是否需要外來鍵。這裡有兩個問題 乙個是如何保證...
資料庫用還是不用外來鍵
資料庫設計中乙個矛盾 資料庫外來鍵,用還是不用？正方觀點 1，由資料庫自身保證資料一致性，完整性，更可靠，因為程式很難100 保證資料的完整性，而用外來鍵即使在資料庫伺服器當機或者出現其他問題的時候，也能夠最大限度的保證資料的一致性和完整性。eg 資料庫和應用是一對多的關係，應用會維護他那部分資料的...