引言

其實(shí)這個(gè)話題是老生常談，很多人在工作中確實(shí)也不會(huì)使用外鍵。包括在阿里的JAVA規(guī)范中也有下面這一條

【強(qiáng)制】不得使用外鍵與級(jí)聯(lián)，一切外鍵概念必須在應(yīng)用層解決。

但是呢，詢問他們?cè)?#xff0c;大多是這么回答的

每次做DELETE 或者UPDATE都必須考慮外鍵約束，會(huì)導(dǎo)致開發(fā)的時(shí)候很痛苦,測(cè)試數(shù)據(jù)極為不方便。

坦白說，這么說也是對(duì)的。但是呢，不夠全面，所以開一文來詳細(xì)說明。

正文

首先我們明確一點(diǎn)，外鍵約束是一種約束，這個(gè)約束的存在，會(huì)保證表間數(shù)據(jù)的關(guān)系“始終完整”。因此，外鍵約束的存在，并非全然沒有優(yōu)點(diǎn)。
比如使用外鍵，可以

• 保證數(shù)據(jù)的完整性和一致性
• 級(jí)聯(lián)操作方便
• 將數(shù)據(jù)完整性判斷托付給了數(shù)據(jù)庫完成，減少了程序的代碼量

然而，魚和熊掌不可兼得。外鍵是能夠保證數(shù)據(jù)的完整性，但是會(huì)給系統(tǒng)帶來很多缺陷。正是因?yàn)檫@些缺陷，才導(dǎo)致我們不推薦使用外鍵，具體如下

性能問題

假設(shè)一張表名為user_tb。那么這張表里有兩個(gè)外鍵字段，指向兩張表。那么，每次往user_tb表里插入數(shù)據(jù)，就必須往兩個(gè)外鍵對(duì)應(yīng)的表里查詢是否有對(duì)應(yīng)數(shù)據(jù)。如果交由程序控制，這種查詢過程就可以控制在我們手里，可以省略一些不必要的查詢過程。但是如果由數(shù)據(jù)庫控制，則是必須要去這兩張表里判斷。

并發(fā)問題

在使用外鍵的情況下，每次修改數(shù)據(jù)都需要去另外一個(gè)表檢查數(shù)據(jù),需要獲取額外的鎖。若是在高并發(fā)大流量事務(wù)場(chǎng)景，使用外鍵更容易造成死鎖。

擴(kuò)展性問題

這里主要是分為兩點(diǎn)

• 做平臺(tái)遷移方便，比如你從Mysql遷移到Oracle，像觸發(fā)器、外鍵這種東西，都可以利用框架本身的特性來實(shí)現(xiàn)，而不用依賴于數(shù)據(jù)庫本身的特性，做遷移更加方便。
• 分庫分表方便，在水平拆分和分庫的情況下，外鍵是無法生效的。將數(shù)據(jù)間關(guān)系的維護(hù)，放入應(yīng)用程序中，為將來的分庫分表省去很多的麻煩。

技術(shù)問題

使用外鍵，其實(shí)將應(yīng)用程序應(yīng)該執(zhí)行的判斷邏輯轉(zhuǎn)移到了數(shù)據(jù)庫上。那么這意味著一點(diǎn)，數(shù)據(jù)庫的性能開銷變大了，那么這就對(duì)DBA的要求就更高了。很多中小型公司由于資金問題，并沒有聘用專業(yè)的DBA，因此他們會(huì)選擇不用外鍵，降低數(shù)據(jù)庫的消耗。
相反的，如果該約束邏輯在應(yīng)用程序中，發(fā)現(xiàn)應(yīng)用服務(wù)器性能不夠，可以加機(jī)器，做水平擴(kuò)展。如果是在數(shù)據(jù)庫服務(wù)器上，數(shù)據(jù)庫服務(wù)器會(huì)成為性能瓶頸，做水平擴(kuò)展比較困難。

轉(zhuǎn)載于:https://www.cnblogs.com/rjzheng/p/9907304.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的【原创】数据库中为什么不推荐使用外键约束的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。