如果搞不清楚要不要用,就不要用!

之前我问dalao:我想使用外键来节约我的代码量,但是mysql中这个表段是MyISAM的,根本就不支持外键,反正没有全表索引,我能不能把MyISAM改成Innodb,既可以使用外键,又不影响原来的业务?

感谢:https://www.zhihu.com/question/19600081

最后当然是被说了一通,Innodb影响性能,一致性可以在代码中加以控制,不需要使用外键之类的…

这个道理我还是懂得的,也很认同dalao的观点,但是只凭一家之言,未免有失偏颇。所以查了下各种开发者对外键的看法,选了一些我认为很好的回答,展示如下。

一、外键是否采用看业务应用场景,以及开发成本的

大致列下什么时候适合,什么时候不适合使用。

(1)互联网行业应用不推荐使用外键。

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

若是把数据一致性的控制放到事务中,也即让应用服务器承担此部分的压力,而引用服务器一般都是可以做到轻松地水平的伸缩。

(2)传统行业

  1. 软件应用的人数有限,换句话说是可控的。
  2. 数据库服务器的数据量也一般不会超大,且活跃数据有限。

综合上述2句话描述,也即数据库服务器的性能不是问题,所以不用过多考虑性能的问题。

另外,使用外键可以降低开发成本,借助数据库产品自身的触发器可以实现表与关联表之间的数据一致性和更新。

最后一点,使用外键的方式,还可以做到开发人员和数据库设计人员的分工,可以为程序员承担更多的工作量;

二、为何说外键有性能问题

  1. 数据库需要维护外键的内部管理。
  2. 外键等于把数据的一致性事务实现,全部交给数据库服务器完成。
  3. 有了外键,当做一些涉及外键字段的增,删,更新操作之后,需要触发相关操作去检查,而不得不消耗资源。
  4. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况。

三、这取决于数据库的用途、规模、架构

有外键,可以提高鲁棒性、健壮性,但是约束检验显然会拖慢速度。

规模上说,数据量大的不适合用外键,小的可以用;用途上安全性、可靠性很重要的就要用外键,否则可以不用。具体情况具体解决了,因为也有矛盾的时候,数据量极大,但是又要求高可靠,例如银行金融、芯片生产等,仍然需要外键的存在。可以通过SAN+RAID等硬件提升解决矛盾。
要求高并发的情况下,并不适合外键,有的连关系数据库都不用了,甚至数据库都不用了。这类问题真没有绝对的答案,什么情况下该怎样做,只能是多想,多做了,错的多了,就懂了。

四、总结

最后还是一句话,要看业务需求。

但是现在我个人认为,如果搞不清楚要不要用,就不要用。

数据库的诸多设计,帐号,权限,约束,触发器,都是为 C/S 结构设计的,是以 C 端不可信做为假设前提的。B/S 模式安全边界前移到 web 服务层,应用与数据库之间是可信的,应用自行完成这些功能更加灵活。

所以能不用就不用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注