外键不推荐使用的理由及相关

￡神魔★判官ぃ 2023-03-01 13:27 10阅读 0赞

## 外键的原理 ##

查询某个数据库的某张表被哪些表的哪些字段作为外键引用了。

select
    TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME
    from INFORMATION_SCHEMA.KEY_COLUMN_USAGE
    where CONSTRAINT_SCHEMA ='数据库' AND
    REFERENCED_TABLE_NAME = '表名';

### 外键的 OnDelete OnUpdate可选项 ###

On Delete和On Update都有Restrict，No Action, Cascade,Set Null属性。现在分别对他们的属性含义做个解释。

ON DELETE

restrict(约束):当在父表（即外键的来源表）中删除对应记录时，首先检查该记录是否有对应外键，如果有则不允许删除。

no action:意思同restrict.即如果存在从数据，不允许删除主数据。

cascade(级联):当在父表（即外键的来源表）中删除对应记录时，首先检查该记录是否有对应外键，如果有则也删除外键在子表（即包含外键的表）中的记录。

set null:当在父表（即外键的来源表）中删除对应记录时，首先检查该记录是否有对应外键，如果有则设置子表中该外键值为null（不过这就要求该外键允许取null）

ON UPDATE

restrict(约束):当在父表（即外键的来源表）中更新对应记录时，首先检查该记录是否有对应外键，如果有则不允许更新。

no action:意思同restrict.

cascade(级联):当在父表（即外键的来源表）中更新对应记录时，首先检查该记录是否有对应外键，如果有则也更新外键在子表（即包含外键的表）中的记录。

set null:当在父表（即外键的来源表）中更新对应记录时，首先检查该记录是否有对应外键，如果有则设置子表中该外键值为null（不过这就要求该外键允许取null）。

注：NO ACTION和RESTRICT的区别：只有在及个别的情况下会导致区别，前者是在其他约束的动作之后执行，后者具有最高的优先权执行。

## 不推荐使用的理由 ##

在阿里的JAVA规范中也有下面这一条

> **【强制】不得使用外键与级联，一切外键概念必须在应用层解决。**

但是呢，询问他们原因，大多是这么回答的

> **每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。**

坦白说，这么说也是对的。但是呢，不够全面，所以开一文来详细说明。

## 正文 ##

首先我们明确一点，外键约束是一种约束，这个约束的存在，会保证表间数据的关系“始终完整”。因此，外键约束的存在，并非全然没有优点。  
比如使用外键，可以

*  保证数据的完整性和一致性
 *  级联操作方便
 *  将数据完整性判断托付给了数据库完成，减少了程序的代码量

然而，鱼和熊掌不可兼得。外键是能够保证数据的完整性，但是会给系统带来很多缺陷。正是因为这些缺陷，才导致我们不推荐使用外键，具体如下

### 性能问题 ###

假设一张表名为user\_tb。那么这张表里有两个外键字段，指向两张表。那么，每次往user\_tb表里插入数据，就必须往两个外键对应的表里查询是否有对应数据。如果交由程序控制，这种查询过程就可以控制在我们手里，可以省略一些不必要的查询过程。但是如果由数据库控制，则是必须要去这两张表里判断。

### 并发问题 ###

在使用外键的情况下，每次修改数据都需要去另外一个表检查数据,需要获取额外的锁。若是在高并发大流量事务场景，使用外键更容易造成死锁。

### 扩展性问题 ###

这里主要是分为两点

*  做平台迁移方便，比如你从`Mysql`迁移到`Oracle`，像触发器、外键这种东西，都可以利用框架本身的特性来实现，而不用依赖于数据库本身的特性，做迁移更加方便。
 *  分库分表方便，在水平拆分和分库的情况下，外键是无法生效的。将数据间关系的维护，放入应用程序中，为将来的分库分表省去很多的麻烦。

### 技术问题 ###

使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。  
相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。