数据库里面不建立主外键关系有什么好处？

不建议建立，使用外键有利于维持数据完整性和一致性，但是对于开发来说是非常不利的。

每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦，而且需要更为复杂的错误捕获机制。

做数据处理时会受到很多的束缚，有些地方本来就可以允许有部分冗余，但是由于设计了外键约束，只能放弃。

出现BUG的时候追踪很麻烦。

数据库的三个层次：

物理数据层是数据库的最内层，是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令 *** 作处理的位串、字符和字组成。

概念数据层是数据库的中间一层，是数据库的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系，而不是它们的物理情况，是数据库管理员概念下的数据库。

用户数据层是用户所看到和使用的数据库，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。

其实这个话题是老生常谈，很多人在工作中确实也不会使用外键。包括在阿里的JAVA规范中也有下面这一条

但是呢，询问他们原因，大多是这么回答的

坦白说，这么说也是对的。但是呢，不够全面，所以开一文来详细说明。

首先我们明确一点，外键约束是一种约束，这个约束的存在，会保证表间数据的关系“始终完整”。因此，外键约束的存在，并非全然没有优点。

比如使用外键，可以

然而，鱼和熊掌不可兼得。外键是能够保证数据的完整性，但是会给系统带来很多缺陷。正是因为这些缺陷，才导致我们不推荐使用外键，具体如下

假设一张表名为user_tb。那么这张表里有两个外键字段，指向两张表。那么，每次往user_tb表里插入数据，就必须往两个外键对应的表里查询是否有对应数据。如果交由程序控制，这种查询过程就可以控制在我们手里，可以省略一些不必要的查询过程。但是如果由数据库控制，则是必须要去这两张表里判断。

在使用外键的情况下，每次修改数据都需要去另外一个表检查数据,需要获取额外的锁。若是在高并发大流量事务场景，使用外键更容易造成死锁。

这里主要是分为两点

使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。

相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。

本人花费2个月时间，整理了一套JAVA开发技术资料，内容涵盖java基础，分布式、微服务等主流技术资料，包含大厂面经，学习笔记、源码讲义、项目实战、讲解视频。

希望可以帮助一些想通过自学提升能力的朋友，领取资料，扫码关注一下

记得转发+关注+私信

私信回复【2022面试资料】

领取更多学习资料

---