外键的设计初衷是为了在数据库端保证对逻辑上相关联的表数据在操作上的一致性与完整性。
外键在大部分企业写的开发规范里会直接规避掉！外键有优缺点，也并不是说每种场景都不适用，完全没有必要一刀切。外键到底能不能用？下面会针对不同的场景来告诉你答案。
一、外键的优缺点
优点：
精简关联数据，减少数据冗余
避免后期对大量冗余处理的额外运维操作。
降低应用代码复杂性，减少了额外的异常处理
相关数据管理全由数据库端处理。
增加文档的可读性
特别是在表设计开始，绘制 ER 图的时候，逻辑简单明了，可读性非常强。
缺点：
性能压力
外键一般会存在级联功能，级联更新，级联删除等等。在海量数据场景，造成很大的性能压力。比如插入一条新记录，如果插入记录的表有 10 个外键，那势必要对关联的 10 张表逐一检查插入的记录是否合理，延误了正常插入的记录时间。并且父表的更新会连带子表加上相关的锁。
其他功能的灵活性不佳
比如，表结构的更新等。
二、外键的使用
外键参照动作列表：
CASCADE：级联，子表跟随父表更新外键值
SET NULL：子表更随主表更新外键值为 NULL
RESTRICT/ NO ACTION：默认，限制父表改动外键值
SET DEFAULT：目前产生的效果和 RESTRICT 相同。
那先来简单看看 MySQL 里外键的用法。MySQL 外键仅有 InnoDB 和 NDB 两种引擎支持，这里只关注 InnoDB。
本次示例 MySQL 的版本为最新版 8.0.19
示例
下面 f1 是父表，f2、f3、f6 分别代表不同类型的外键表，也就是子表。
1.
2.
3.
4.
6.
7.
8.
9.
12.
13.
14.
15.
17.
18.
19.
20.
场景一：强烈要求数据一致性，程序弱化，数据库端强化，表结构改动小，并发不高的场景。
用一条记录验证表 f2 和 f6。从功能性角度来看，外键的优势很明显，在数据库端完全满足了数据完整性校验。
1.
2.
4.
5.
7.
8.
10.
11.
12.
13.
15.
16.
17.
18.
19.
20.
21.
22.
24.
25.
26.
场景二：频繁的数据装载，但是也严格要求数据库端保证数据一致性。
这里只验证表 f6，同时克隆一张新表 f6_no_fk，除了没有外键，表结构和 f6 一样。导入 400W 条样例数据。
1.
2.
3.
4.
6.
7.
8.
9.
从上面看到，单独的测试导入 400W 条记录，带有外键的表比非外键的表时间上没有优势。那针对上面的场景优化下，关闭外键检查参数，导入完成后，再开启。
1.
2.
4.
5.
6.
8.
9.
10.
11.
13.
14.
15.
从以上结果看出，关闭外键检查后，导入时间和没有外键的表 f6_no_fk 差不多。
场景三：并发少，事物块简单。
接下来再看下简单的事物块提交方式，我简单写了一个每 500 条记录提交一次的存储过程。
1.
2.
3.
4.
5.
6.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
接下来插入 100W 条记录，
1.
2.
3.
5.
6.
7.
9.
10.
11.
13.
14.
15.
17.
18.
从测试的结果来看，有外键和没有外键的检索时间在这样的场景下也相差无几。
场景四：主表的外键引用字段类型要扩充，原来的数据溢出，没法保存更大的值。
比如此时字段 r2 定义的数据类型不合适了，需要更改为大点的，比如以下，直接修改会报错，
1.
2.
4.
5.
那怎么改呢？需要先把外键删掉，修改完了类型，再加上约束。这种场景就不太适合用外键。
1.
2.
3.
5.
6.
7.
9.
10.
11.
13.
14.
15.
场景五：子表有触发器需求来更新必要的字段。
那关于这点就是，子表的触发器不会随着父表的更新级联应用，也就是此时触发器失效。举个例子，往 f2 上添加一个 before update 触发器。
1.
2.
3.
5.
6.
8.
9.
10.
11.
12.
13.
14.
16.
18.
19.
20.
22.
23.
24.
25.
26.
27.
28.
29.
31.
32.
33.
34.
36.
37.
38.
39.
40.
41.
42.
43.
场景六：父表为分区表，有外键的需求。
那针对分区表，暂时不支持子表以分区表为父表的外键。
1.
2.
4.
5.
6.
8.
9.
10.
场景七：日常并发很高的场景，应该尽量减少相关事务锁的范围和量级。
那举个简单例子，看看有外键情况下，父表更新，子表级联加锁的情形。
1.
2.
3.
5.
6.
7.
10.
11.
12.
13.
14.
15.
16.
总共有 11 个锁，也就简单的执行了下 Update，而且更新的只是一行。
1.
2.
3.
4.
5.
6.
7.
8.
查看锁的细化，父有 f1 有 5 个锁，子表 f6 有 6 个锁。这都是 MySQL 为了保证数据一致性强制加的，这点在 TPS 要求比较高的场景肯定不合适，
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
三、外键的限制：
1. 仅有 InnoDB 和 NDB 引擎支持。
2. 不支持虚拟列。
3. 不支持临时表。
4. 外键列以及引用列数据类型、字符集、校对规则都得一致。
5. 外键列以及引用列都必须建立索引。
6. 外键引用多个列的，列顺序必须一致。
7. 大对象字段不能作为引用列。
8. constraint 命名必须在单个 database 里唯一。
9. 外键级联更新操作不会触发子表上的触发器。
10. 不支持分区表。
总结
本文主要从几个例子来演示了，外键是否应该使用以及在哪些场景下使用，让大家了解外键的详细需求。
从上面我描述的几个场景来说，场景 1,2,3 很适合用外键；场景 4,5,6,7 就不太适合用外键；可以把外键功能放在数据库之外实现。
关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/sqlbc/54353.html