为啥不推荐使用数据库外键
前言
在阿里开发手册中写道：不得使用外键与级联，一切外键概念必须在应用层解决。
说明：（概念解释）学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。
-
适应分布式、高并发环境：外键与级联更新适用于单机低并发环境，但在分布式、高并发集群环境下，存在诸多问题。比如级联更新是强阻塞的，当更新主表中的外键字段时，会触发相关从表的级联更新操作，在高并发情况下，大量的级联更新请求可能会相互阻塞，形成数据库更新风暴，导致数据库性能急剧下降甚至瘫痪，严重影响系统的可用性和稳定性。
-
提高插入速度，降低数据库负担：外键的存在会影响数据库的插入速度，因为在插入数据时，数据库需要额外检查外键约束，确保插入的数据符合外键关联关系，这增加了插入操作的开销。在应用层解决外键概念，可以避免这种因外键约束检查带来的性能损耗，让数据库插入操作更加高效，同时也降低了数据库的复杂度和维护成本，便于应对大规模数据和高并发的业务场景。
什么是外键
外键 (foreign Key)是用于建立和加强两个表数据之间的链接的一列或多列。外键表示一个表中的一个字段被另一个表中的一个字段引用。外键对相关表中的数据造成了限制，使MySQL能够保持参照完整性外键约束主要用来维护两个表之间数据的一致性。简言之，表的外键就是另一表的主键，外键将两表联系起来。一般情况下，要删除一张表中的主键必须首先要确保其它表中的没有相同外键 (即该表中的主键没有一个外键和它相关联)。
可见，外键本身的束缚就很多了
场景分析
假设我们是在做一个电商的项目，我们有一张用户表，有一张商品表有一张订单表。订单表的用户id和用户表构成一个外键，订单表的商品id再和商品表构成一个外键。那么此时我生成一笔订单会发生什么?由于外键的一致特性，我每次插入一个订单，就要去查询用户表和商品表是否存在相应的数据，没有则会报错，这就很难受了。由此引发的问题
1、触发查询操作，造成额外的性能消耗 2、在进行查询的时候，会触发内部锁，这个锁可能会造成高并发死锁 3、用了外键就意味着我们把所有的数据一致性交由数据库处理，就不能最终一致性的操作 4、以后分库分表直接心态爆炸
解决方案
目前现在主流的都是不使用外键，采用业务逻辑关联的方式，来模拟这种外键。我们不需要由数据库来保证任何的一致性，不产生额外的表关联查询等操作。举个场景的例子呀，订单表存一个user_id字段，对应user表的主键，但二者无强一致关系只要我们的数据库层面不产生任何的强制耦合，我们就可以再业务层采用各种方案。我们可以采用最终一致性的方案，有时候高并发的情况下我们可以先更新部分表，再由消息驱动等方式来进行其他数据的补偿，而使用了外键，直接强一致性了。
优势
1、减少了额外的查询，不用检查数据是否违反完整性，提升了性能。 2、数据源进行切换的时候，不互相产生影响。 3、分库分表十分方便，不存在强制耦合 4、刷数据方便，有时候，我们可能要批量导入数据，这个时候如果有外键，就很难受了，你要确定数据导入的顺序。