如果被引用的表需要做分庫分表，那么無法建立外鍵約束。

使用外鍵會降低數據庫性能，這個說法并不細致。需要詳細分析。

建立外鍵，那么一般引用字段上需要建立索引。如果不建立索引，被引用的表上刪除數據，會全表掃描引用表。被引用表上刪除數據速度奇慢。(如果引用表從來不刪除數據不修改主鍵可以不建立這個索引)。

索引會降低插入刪除速度，降低(修改了索引字段值的)修改操作的速度。

從這個角度來說，建立了外鍵，無論是否建立外鍵字段上的索引，總有速度變慢了。但是，如果外鍵字段上本身也有查詢需求，這個索引就不能省了。

另外，還有一個流行的說法是：數據庫擴容不易，容易成為瓶頸，所以將數據完整性校驗交給應用層做，不適用數據庫(外鍵機制)來做。

這個說法是不準確的。 OLTP使用場景的數據庫，主要是消耗磁盤IO。數據庫的瓶頸一般也是磁盤IO。無論是應用層做校驗，還是外鍵機制校驗，磁盤IO是省不的。

內存和CPU很難成為數據庫的瓶頸，因為PC服務器已經可以支持128核CPU，若干T的內存。

了解完外鍵對數據庫性能的影響。那么我們就能容易的得到結論：

如果被引用的表需要做分庫分表，那么無法建立外鍵約束。

如果數據量很大，但不會分庫分表。引用字段不會作為查詢條件(無建立索引需求)，可以考慮不使用外鍵。但是仍然建議使用。因為不使用外鍵會額外增加代碼量增加人工成本，人比較貴，cpu/內存/磁盤比較便宜。

一般系統，單表記錄數不超過千萬的。強烈建議使用外鍵約束來檢查數據完整性。

ps: 一個人經驗，企業應用，數據庫沒有外鍵的，運行幾年后，95%的系統數據庫里的數據對不上。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的mysql建表时建外键约束_数据库建表时一定要设置外键约束关系吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。