为什么禁止使用外键
外键的优点
一、数据一致性
由数据库自身保证数据一致性、完整性会更可靠，程序很难100％保证数据的一致性、完整性
二、ER图可靠性
有主外键的数据库设计可以增加ER图的可读性
外键的缺点
一、级联问题
阿里巴巴的开发手册中，就曾指出强制要求不允许使用外键，一切外键概念必须在应用层解决。 因为每次级联delete或update的时候，都要级联操作相关的外键表，不论有没有这个必要，由其在高并发的场景下，这会导致性能瓶颈
二、增加数据库压力
外键等于把数据的一致性事务实现，全部交给数据库服务器完成，并且有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源
三、死锁问题
若是高并发大流量事务场景，使用外键还可能容易造成死锁
四、开发不方便
有外键时，无论开发还是维护，需要手工维护数据时，都不太方便，要考虑级联因素
总结
一、如是单机且低并发，也不需要性能调优，再或者不能用程序保证数据的一致性，完整性，可以使用外键
二、如果为了高并发，分布式，使系统性能更优，以及更好维护，则一定不能使用外键
引言
其实这个话题是老生常谈，很多人在工作中确实也不会使用外键。包括在阿里的JAVA规范中也有下面这一条
**【强制】不得使用外键与级联，一切外键概念必须在应用层解决。 **
但是呢，询问他们原因，大多是这么回答的
每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。
坦白说，这么说也是对的。但是呢，不够全面，所以开一文来详细说明。
正文
首先我们明确一点，外键约束是一种约束，这个约束的存在，会保证表间数据的关系“始终完整”。因此，外键约束的存在，并非全然没有优点。
比如使用外键，可以
- 保证数据的完整性和一致性
- 级联操作方便
- 将数据完整性判断托付给了数据库完成，减少了程序的代码量
然而，鱼和熊掌不可兼得。外键是能够保证数据的完整性，但是会给系统带来很多缺陷。正是因为这些缺陷，才导致我们不推荐使用外键，具体如下
性能问题
假设一张表名为user_tb。那么这张表里有两个外键字段，指向两张表。那么，每次往user_tb表里插入数据，就必须往两个外键对应的表里查询是否有对应数据。如果交由程序控制，这种查询过程就可以控制在我们手里，可以省略一些不必要的查询过程。但是如果由数据库控制，则是必须要去这两张表里判断。
并发问题
在使用外键的情况下，每次修改数据都需要去另外一个表检查数据,需要获取额外的锁。若是在高并发大流量事务场景，使用外键更容易造成死锁。
扩展性问题
这里主要是分为两点
- 做平台迁移方便，比如你从
Mysql迁移到Oracle，像触发器、外键这种东西，都可以利用框架本身的特性来实现，而不用依赖于数据库本身的特性，做迁移更加方便。 - 分库分表方便，在水平拆分和分库的情况下，外键是无法生效的。将数据间关系的维护，放入应用程序中，为将来的分库分表省去很多的麻烦。
技术问题
使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。
相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。
