数据库中，到底该不该使用外键

到底应不应该建立外键关系？

我们首先要知道我们纠结的这个问题的本质是什么，其本质其实是数据一致性的问题。

数据一致性是我们的目的，而建立外键只是我们维护数据一致性的一种手段。

但是我们要知道，维护数据一致性可不止建立外键这一种方式。

 

建立外键是在数据库层面进行数据一致性的维护，可以让我们在代码的编写过程中不要去考虑数据一致性的这种问题。

但是在一些庞大的系统中，这种外键关系可能会非常的复制，这样我们在进行数据维护的时候，数据库会进行非常多的校验，降低了数据库运行的性能。

例如下面这种关系，我们的字典表和用户表可能会被多个表建立外键关联。

除此之外，也会降低我们数据库设计的灵活性，我们一个系统，随着时间的推移，单个数据库单个表的数据量可能会越来越大。

这时候我们为了提高性能，可能会将一个数据库划分为多个数据库 ，单个表也可能会被划分为多个表。将大块的数据划分成小块的数据，将小块的数据保存到多台服务器上。这时候如果我们一些表建立了主外键关系，这种拆解是会出现问题的。

而且

我们在数据库中建立了主外键关系之后，就在编写代码的过程中就真的不需要去考虑数据一致性的问题吗。

假如我们在程序中去删除一条被外键关联的数据，数据库建立了外键关系，他会禁止我们去删除，结果会返回一个错误给我们的程序，归根到底，还是需要我们自己去处理这个数据一致性的问题，去程序中修改这个bug。

我们只能依赖数据库中的主外键关系来帮助我们效验程序的正确性，而不是我们完全的就把这个问题交给数据库了。

 

回到我们问题的根源，数据一致性的问题。

在真实的生产环境中，有时候是可以容忍数据一致性的问题的，这个要求并不严格，所以这时候我们可以不去设置外键，即使出现一点数据一致性问题，我们也可以容忍。但是也不是说完全就不去管，我们可以在测试环境中设置主外键关系，以此来帮助我们效验程序，但是到了线上，我们将这种主外键关系去掉。我们在程序中去记录好日志，一旦发生bug，可以用日志来查找出bug

但是有的时候我们对数据一致性是严格要求的，宁可程序不能使用，也不想发生数据一致性问题，这时候我们可以设置外键关系。

 

使用外键：

优点：

（1）实现表与关联表之间的数据一致性；

（2）可以迅速的建立一个可靠性非常高的数据库结构，而不用让应用程序层去做过多的检查；

（3）可以提高系统健壮性；

（4）可以实现开发人员和数据库设计人员的分工；

　　缺点：

（1）数据库需要维护外键的内部管理；

（2）外键等于把数据的一致性事务实现，全部交给数据库服务器完成；

（3）有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；

（4）外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

（5）容易出现数据库I/O的瓶颈；

不使用外键

优点：

（1）减少了数据库表与表之间各种关联的复杂性；

（2）牺牲应用服务器资源，换取数据库服务器的性能；

（3）将主动权把控在自己手里；

（4）去掉外键相当于优化数据库性能；

缺点：

（1）所有外键的约束，需要自己在逻辑层自己实现；

（2）会出现数据错误覆写，错误数据进库的情况；

（3）消耗了服务器的性能；

（4）业务层里夹带持久层特性，耦合；

 

总结：

1. 互联网行业：不推荐使用外键。

　　　　理由：1）用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；

　　　　　　　2）若是把数据一致性的控制放到事务中，即让应用服务器承担此部分的压力；

　　　　　　    3）应用服务器一般都是可以做到轻松地水平的伸缩；

 

2. 传统行业：可以使用。

              理由：1）软件应用的人数有限，换句话说是可控的；

　　                  2）数据库服务器的数据量也一般不会超大，且活跃数据有限；