在分布式大行其道的今天，为什么外键约束越来越少？
外键-数据链接带来强制完整性
在关系型数据库中，外键（Foreign Key）可以用于建立和强制两个表之间的数据链接。
在层次数据结构一篇的闭包表简单设计中，就有使用外键进行数据链接。
像这样：
我们很容易发现，外键最直接的体现是强制完整性，即引用表中的外键值必须先存在于被引用表。
删除被引用的行数据时，必须先删除引用表数据（级联删除）。
通过外键，我们很容易理清楚表之间的关系，即理解数据模型，且也有利于ER图的生成和可视化。
外键-强制完整性不适应微服务
分布式与微服务追求服务的自洽 ，要求服务具备独立性，要求架构整体具备容错，服务之间不会互相阻塞。
这些与外键的强制关联特性相冲突。
且在数据库与服务基本是N对N的环境下，数据库外键约束通常无法跨越不同的数据库实例或服务边界 来强制执行。
另外数据库每次执行外键操作还需要额外的检查来验证外键约束。在高并发、高写入吞吐量的场景下，这样的额外开销可能会成为性能瓶颈。
因此，高耦合强制的外键，并不适应现在主流的微服务、分布式。
应用层处理代替外键约束
外键不合适了，但是外键要做的事情却不能不做，常见的做法是在应用层完成外键原本的工作。
-
数据链接
在执行删除或更新操作前，应用程序代码需要检查是否存在关联数据。
通过逻辑删除，保留数据的链接。
-
数据稽核
建立一个稽核系统，处理数据的不一致与孤儿数据（在引用表有数据，被引用表没有数据）。