数据库该不该用外键

明确说，不该用。

1. 外键属于业务需求

2. 在数据量稍微大点的数据库极大影响性能。

3. 影响业务扩展，并且业务本身能够代替处理一致性关联。

即便业务端忘记处理关联信息的删除，也不影响最终查询结果。比如user和user_info表， user删除了，user_info忘记删除。正常关联user_info表， 左连user结果正常。仅仅增加冗余数据而已。相比检索写入性能的指数级降低，业务处理更好。况且，现在也不会真的删除一条记录，仅仅一个标记。忘记标记某给表，影响不大。

外键的设计初衷是为了在数据库端保证对逻辑上相关联的表数据在 *** 作上的一致性与完整性。

优点：

精简关联数据，减少数据冗余

避免后期对大量冗余处理的额外运维 *** 作。

降低应用代码复杂性，减少了额外的异常处理

相关数据管理全由数据库端处理。

增加文档的可读性

特别是在表设计开始，绘制 ER 图的时候，逻辑简单明了，可读性非常强。

缺点：

性能压力

外键一般会存在级联功能，级联更新，级联删除等等。在海量数据场景，造成很大的性能压力。比如插入一条新记录，如果插入记录的表有 10 个外键，那势必要对关联的 10 张表逐一检查插入的记录是否合理，延误了正常插入的记录时间。并且父表的更新会连带子表加上相关的锁。

其他功能的灵活性不佳

比如，表结构的更新等。

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

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

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

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

比如使用外键，可以

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

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

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

这里主要是分为两点

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

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

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

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

记得转发+关注+私信

私信回复【2022面试资料】

领取更多学习资料

---