在以前学习数据相关知识的时候，有幸阅读过阿里的数据库开发规范手册，里面提到一条强制等级的规范：不得使用外键与级联，一切外键概念必须在应用层解决。

当时我就很困惑，外键约束挺方便的，为什么大厂的规范中直接被强制禁用了？

虽然手册后面讲了原因，但当时身为小白的我还是一知半解的，直到在工作岗位上被“上了一课”。

数据库有无外键约束的区别

有外键

每次向数据库添加数据都需要去检查外键约束，检查关联表是否已经存在数据，硬性保持数据一致性，如果一条记录中存在多个外键，这样的buff还将会被叠加（性能损耗加成）。

无外键

不检查外键的合法性，直接插入。

外键在大型项目中带来的麻烦

数据库更新风暴： 在数据库系统中大规模的、瞬时性的更新操作，通常会导致数据库性能下降或者服务不稳定。这种情况通常发生在有大量并发用户或者应用程序同时对数据库进行写操作时，特别是在没有有效控制并发访问的情况下。

在发生数据库更新风暴时会导致的问题：

性能下降：大规模的写操作会导致数据库系统负载增加，可能导致查询响应时间延长或者系统整体性能下降。

锁竞争：多个并发写操作可能导致锁竞争，进而影响系统的并发性能和吞吐量。

死锁：如果更新操作涉及多个数据表或者多个数据行，并且没有正确处理事务和锁定，可能会导致死锁，进而影响系统稳定性。

数据一致性问题：大规模更新操作可能会导致数据一致性问题，例如数据丢失、数据错误或者数据不一致的情况发生。（数据缺失比数据错误要更严重。）

外键难以跨越数据库使用：在大型项目中，当数据量特别大的时候，一般会采取分库分表来存储数据。

但在不同的库中使用相同的外键来维护数据一致性和完整性是非常难的操作。所以在分布式、高并发集群的项目数据库中一般看不到外键的存在。

最后

外键是否采用，具体还要看业务应用场景，以及开发成本的。

中大型项目：

不推荐使用外键， 用户量大，并发高，数据库容易成为性能瓶颈，尤其受IO限制，此时不用外键，把数据一致性的控制放到程序事务中，易于水平扩展。

小型项目：

软件应用的用户数有限，数据量也一般不会超大，且活跃数据有限。即数据库服务器的性能不是问题，不用过多考虑性能问题。