禁用外键约束是什么

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

为什么禁用外键约束

首先，假设我们用了数据库约束外键，每次做 DELETE 或者 UPDATE 都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。

如果测试或者开发时我们需要删除某个表的数据，如果此时使用了外键约束与此表有十几个关联，那岂不是要炸毛了。当然这是使用层面带来的麻烦。

当然使用外键约束也有优点，保证数据的完整性和一致性、级联操作方便、数据一致性交给数据库、代码量小。任何事情都会有利有弊。

接下来我们通过案例进行讲解

案例讲解

这是一个很常见的订单与订单明细表，订单表的主键与订单明细表的订单 Id 存在外键约束关系

数据库层面外键约束维度

1 . 性能问题

额外的数据一致性校验查询，当在订单明细表进行数据插入操作时，会检查订单表里是否存在对于的外键约束数据

2 . 并发问题

外界约束会启用行级锁，主表写入时会进入阻塞，什么意思呢？

当用户买了十几样商品，在对于的订单明细表就会有十几行数据，再每次插入的时候，都会去检查订单表里是否存在订单 ID ，这是正常的流程。

但是，如果在并发环境下，订单明细表向订单表检查外键约束关系的时候，会在订单表开启一个共享锁（读锁）。

如果此时甭管什么原因，此时有个请求需要修改订单表的订单 ID ，此时订单表就会开启一个排它锁（写锁）。那么此时订单明细表就会进入一个阻塞的状态，就行进行一个线程的挤压，进而引发系统崩溃。

3 . 级联删除问题

多层级联删除会让数据变得不可控，触发器也严格被禁用，什么意思呢？

如果此时我们想删除订单类型，应为订单表与订单类型表存在外键约束关系，那么对于的订单表里的此类型的订单都将会被删除，订单明细表的明细也将会删除。如果存在更多的外键约束关系，则会删除一连串的数据，此时就会变得不可控。

这些操作都是在数据库层面发生的，都是无法追溯的，是一件很麻烦的事。所以在实际开发中数据库层面的外键约束是严令禁止的。

4 . 数据耦合

数据库层面数据关系产生耦合，数据迁移维护困难，什么意思呢？

如果某一天，订单明细表的数据量过大，基于 MySQL 本身的性能应用已经不足以支持相对应的业务需求。此时计划将订单明细数据迁移到 HBASE 这样的大数据数据库进行存储。

那么此时是不是需要将原有的主外键约束关系给去掉，之后又如何保证数据的一致性问题呢，此时只能通过程序层面进行约束，这是不是又回到了应用层面。

在实际的项目经验过程中，随着业务发展，有些业务数据就会非常大，而应为关系型数据库本身的性能问题，此时有些数据就会进行一些迁移，这是非常常见的，而此时就需要在应用层面确保数据的一致性，所以也就是有些公司为什么不推荐使用外键约束的原因。