一文一点 | 为什么不建议使用数据库外键

你好，这是【一文一点】的第1篇文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。

有的SQL规约是这么说的：

【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

那先复习下是什么外键，举一个最熟悉的例子：

学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。

再复习下什么是级联，还是上面这个例子：

如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，则为级联更新。

用外键不好么，不太好，但也注意，不是不可以，是不建议。

那么这里的不建议，其实也有两说的。

1、如果你为了追求正确性优先于性能的话，可以使用。

2、如果你是单机的并发量少的应用，可以使用，不过这种应用目前在互联网应用里面几乎不存在。

3、所以说，在互联网场景里面，涉及到高并发，在外键的约束下，大量的插入、更新、删除操作的性能会降低。

那么外键为什么有性能问题呢

1、数据库需要额外的维护外键自身的内部管理；

2、外键相当于把数据的一致性事务的实现，全部交给了数据库服务器来完成；

3、有了外键以后，当做一些涉及到外键字段的增，删，改操作时，需要触发相关操作去检查，而不得不消耗资源；

4、每次更新数据，都需要额外的检查另外一张表的数据，容易造成死锁；

总结：

1、互联网行业场景中不推荐使用外键，用户量大，并发度高，如果使用外键，数据库服务器很容易产生性能瓶颈。

2、传统行业可以使用，强调数据强一致性，而且用户数量有限，可控。

基于此，互联网场景中都是不建议使用外键的，外键与级联更新适用于单机低并发，不适合分布式、高并发集群。

外键的实质是形成一种 “约束”。

有了这个约束的存在，原则上就能保证表与表之间数据“始终完整、一致”的关系。

但是在我们平时的实际需求中，通常保证“最终完整、一致” 就可以了，甚至可以容忍一些 “最终不完整、不一致”。

其实，也就是我们常说的大部分业务场景，只需要保持最终一致性，就可以了。

所以放弃外键的根本原因是——我们不再需要这个约束。

七夕快乐。