1樓：遺跡
二來就是不用外來鍵的場景基本上資料錯了就錯了，問題不大，不想花費讓db自己維護資料關係的效能代價
用不用還是得自己感覺，大多數情況下在一致性上資料庫都比應用自己寫的邏輯靠譜
2樓：李豫君
效能問題
做所有寫入操作都會檢查，這樣會導致加鎖。若是在高併發大流量事務場景，使用外來鍵更容易造成死鎖。
如果有兩個外來鍵，如果交給資料庫，兩張表都會被查詢，如果交給自己，會減少一些不必要的查詢。
擴充套件問題
分庫分表方便，在水平拆分和分庫的情況下，外來鍵是無法生效的。將資料間關係的維護，放入應用程式中，為將來的分庫分表省去很多的麻煩。
3樓：xchliu
因為，大部分情況下，使用外來鍵帶來的一致性約束收益，和因為外來鍵帶來的資料問題，故障問題，備份問題。。。比較起來，價效比不高。
4樓：阿爾卡爾
我認為主要還是效能和併發鎖的問題
如果完全按正規化設計，一條交易記錄，乙個帖子，一篇文章，這種屬性比較多的，如果有好幾個列都有外來鍵，關聯的東西太多了，效能是個問題。鎖的東西也多。好多參數列作為父表，本身還有好多別的屬性，你這動一下就都給鎖了，系統的併發度就嚴重下降了
5樓：jecqiang
禁止使用外來鍵外來鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql 的效能，甚至會造成死鎖。
在高併發情況下容易造成資料庫效能，外來鍵與級聯更新適用於單機低併發，不適合分布式、高併發集群；級聯更新是強阻塞，存在資料庫更新風暴的風險；外來鍵影響資料庫的插入速度。
高併發業務解放資料庫CPU，將計算轉移到服務層，併發量大的情況下，這些功能很可能將資料庫拖死，業務邏輯放到服務層具備更好的擴充套件性，能夠輕易實現「增機器就加效能」。讓資料庫只做擅長的事。
6樓：殘風
現代程式設計中受大資料影響，資料庫職責就是儲存資料，取資料，其他的事務，檢視，外來鍵等會影響效能，負載大了很容易就拖死。
複雜業務結構一般都是用程式，結構設計，Redis等來代替，這樣就可以分散資料庫壓力…
7樓：
過去參與的專案中有的在資料庫中加了外來鍵的強約束，有的則沒有，有的是在用PD設計時加上了主從引用關係，但在匯入到庫中時去掉了外來鍵的強約束，而只保留表結構。
表面看，資料庫中加上外來鍵、非空、唯一等強約束會給程式編寫帶來麻煩，實則不然。約束是為了保證資料的合理性，如果資料庫設計的約束本身沒問題，那程式編寫中因約束而照成的不便就多是程式本身的不合理造成的。萬千世界，所有約束規範都是為了確保被約束規範的物件將所參與的事情做的更好，這種最終的好不是只針對某個物件的，而是針對所有參與其中的。
假如某種規範不是這樣，那它本身就是不合理的；假如它是這樣的，而被約束規範的物件覺得在這種約束下做事情不便，那就是他自己做事方法的問題了，要由他自己根據規範修正。
所以強約束帶來的不便只幻象，這種不便不但不是壞事，還會倒逼程式開發更加趨於合理，修正開發中的錯誤。而不加強約束，程式可以肆無忌憚的對資料庫進行任何操作時，如果架構設計師及開發人員的經驗、技能較強還好，否則的話，程式很可能會因有意無意讀寫錯誤資訊，造成針對資料庫的無效或錯誤操作，破壞掉資料的完整性、合理性。
有些情況下，加不加強約束設計者是決定不了的，比如公司有通用的許可權管理系統對所有子專案統一管理，那在設計子專案的資料庫時就不能新增和使用者相關的外來鍵約束了。還有其它類似的情況：兩個專案之間有邏輯交差，但資料庫相互隔離，只能通過互相呼叫介面處理業務。
這種情況下，如果想保證好資料的完整性準確性，只能由程式在業務邏輯層控制，必須設計開發足夠精密才能做好。
8樓：eechen
MySQL預設的儲存引擎InnoDB支援外來鍵,如果一定要用外來鍵,那就要求用InnoDB引擎.
CREATE TABLE `score` (
`student_id` int(10) unsigned DEFAULT NULL,
`course_id` int(10) unsigned DEFAULT NULL,
`score` int(3) unsigned NOT NULL,
UNIQUE KEY `uniq_stu_cou` (`student_id`,`course_id`),
KEY `idx_stu` (`student_id`),
KEY `idx_cou` (`course_id`),
CONSTRAINT `score_ibfk_1` FOREIGN KEY (`student_id`) REFERENCES `student` (`id`)
ON DELETE RESTRICT
ON UPDATE RESTRICT,
CONSTRAINT `score_ibfk_2` FOREIGN KEY (`course_id`) REFERENCES `course` (`id`)
ON DELETE RESTRICT
ON UPDATE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
外來鍵約束有下面幾種:
ON UPDATE CASCADE 級聯更新(更新主鍵表student表裡記錄時,外來鍵表score裡對應的記錄會跟著更新)
ON UPDATE RESTRICT 限制更新(更新主鍵表student表裡記錄時,如果外來鍵表score裡存在對應的記錄時會被拒絕)
ON DELETE CASCADE 和 ON DELETE RESTRICT 是衝突的,不能同時使用.
ON UPDATE CASCADE 和 ON UPDATE RESTRICT 也是如此.
外來鍵約束下,每次INSERT/UPDATE/DELETE寫操作都會給資料庫帶來額外的邏輯壓力.
插入乙個主鍵表中沒有的主鍵編號到外來鍵表中,因為外來鍵約束會導致出錯.
另外,資料量很大時,如果有外來鍵約束,那分表操作就不好搞.
總而言之,外來鍵約束像一把雙刃劍,用不到位反而會傷到自己,把簡單問題複雜化.
9樓：Vincent Zhang
因為外來鍵是一種「約束」。
這個約束的存在，會保證表間資料的關係「始終完整」。
而日常需求中，通常保證「最終完整」就可以了，甚至可以容忍一些「最終不完整」。
所以放棄外來鍵的根本原因是——我們不需要這個約束。
如果使用外來鍵，給自己找麻煩不說，還會帶來額外的效能損失。
同樣做為約束的主鍵，就是十分必要的存在。否則需要應用層達成資料唯一性是很麻煩的。
10樓：風三
其實不光是mysql，從DBA的角度出發，我也不建議在oracle裡使用外來鍵。
外來鍵的效果完全可以通過業務邏輯來保證，但是它帶來的一系列效能問題卻很難有辦法解決。
11樓：ScienJus
使用外來鍵的目的是保證資料的完整性，但是這樣會帶來額外的效能上的開銷。替代的做法是可以在應用程式中完成這一步，並且可以通過非同步處理增加效率。其次外來鍵在水平分表和分庫的情況下就無法使用了。
為什麼mysql的redo日誌不直接記錄sql語句
零五 題主所說的日誌是binlog，而不是redo log，因為binlog是二進位制形式的，所以你不能直觀地看到insert，alter之類的語句。redolog和undolog是對資料庫事務的日誌，它們的物件是資料，而不是操作日誌。innodb引擎下，對資料的修改的步驟是這樣 1 將操作記錄 完...
為什麼不推薦專業很多答案都是會計？
馬特奧Mateo 乙個人說某個行業差可能是偶然，兩個人說某個行業差可能是巧合。但是不推薦行業榜首是會計，那就說明這個行業本身絕對有很大的問題。無可非議會計是很穩定的，穩定的令人髮指。無論薪資還是晉公升。都會說每個行業都是從基層做起，但是你也要看看每個行業管理層和基層的比率啊！會計行業估計前三甲沒跑，...
為什麼看很多人不推薦浙大電氣考研？
只顧風雨兼程 浙大電氣前幾年考研難度太高，其實是難於清華的。這是因為很多人腦補了清華很難，自己考個浙大既符合自己實力又相對有逼格，實際上這種思想造成了浙大考研實際上比清華要難。那些考清華的，你去問問他們考浙大能不能上岸，我估計十個起碼有八個會說不確定。電路哥也說浙大實際難於清華，本科985的有實力最...