数据库里加外键到底好不好？优缺点那些事儿聊聊看

开门见山地说,数据库里加外键这事儿，就像给家里的东西建立一套归属关系一样，它是个让人又爱又恨的工具，你说它不好吧，它能帮你避免很多低级错误；你说它绝对好吧，有时候它又显得有点“碍手碍脚”，咱们今天就不扯那些难懂的专业术语，就用大白话聊聊它的那些优点和缺点。

先说说加外键的好处，也就是你为什么应该考虑用它。

第一个大好处,也是最重要的好处，就是保证数据的一致性和完整性（这个观点在众多数据库基础教材中都有强调，数据库系统概念》），这是什么意思呢？举个例子，你有一个“订单表”，里面有一个“用户ID”字段，指向“用户表”的主键，如果没加外键约束，我就可以随便在“订单表”里写一个根本不存在的“用户ID”，比如99999，这会导致什么后果？当你以后想查这个订单是谁下的，系统就懵了，找不到对应的用户，这就产生了“脏数据”，数据乱七八糟的，但如果你加了外键，数据库就会像个严格的管家，在你插入这条不存在的用户ID的订单时，立刻跳出来阻止你，说：“对不起，这个用户不存在，你不能这么干！” 这就从根本上避免了孤儿数据的存在，让你的数据始终保持干净和关联正确。

第二个好处是,它能给数据表之间建立清晰的文档关系（这种设计意图的明确性在软件工程实践中被广泛认可），对于新接手项目的程序员来说，看着数据库表结构，如果有关键约束，他就能一眼看出来：“哦，订单表里的用户ID是关联到用户表的。” 这比去翻厚厚的设计文档要直观多了，外键本身就是一种注释，说明了表与表之间是怎么联系的，降低了理解和维护的成本。

第三个好处是,可以进行级联操作，省心省力（这是数据库管理系统提供的一项便利功能），还是用订单的例子，假如一个用户注销了账号，你需要删除“用户表”里的这条记录，这个用户之前下的所有订单记录怎么办呢？如果没有外键的级联删除功能，你就得手动地、先一条一条地去删除“订单表”里所有这个用户的订单，然后才能删除用户，这个过程很麻烦，而且容易出错，但如果设置了外键并开启了“级联删除”，你只需要执行一条删除用户的命令，数据库会自动、准确地把这个用户对应的所有订单都删掉，非常方便，同样，也有级联更新，比如用户ID变了，关联的数据也会自动跟着变。

听上去外键简直完美无缺？别急，它的缺点也同样明显，尤其是在一些特定的场景下。

第一个让人头疼的缺点就是对性能的影响（在高并发、大规模数据处理的互联网业务中，这一缺点被频繁提及），你想想，每次你往“订单表”里插入一条新数据，数据库都要额外做一次检查：跑去“用户表”里看看这个ID存不存在，这个检查的动作，虽然单次很快，但在每秒要处理几万甚至几十万笔订单的高并发场景下，每一次检查都是一次微小的开销，积少成多，就会成为性能瓶颈，它相当于给数据写入操作增加了一道“安检”，安检固然安全，但肯定会让通行速度变慢，很多大型互联网应用为了极致的写入速度，会选择在数据库层面放弃外键约束，把保证数据一致性的责任转移到应用程序代码中。

第二个缺点是,它增加了开发的复杂性，尤其是在进行数据变更和维护时，你现在想删除一个用户，但因为外键约束的存在，数据库会阻止你，除非你先处理好它所有的订单，这虽然保证了数据安全，但也意味着你的删除操作不能一步到位，需要按照严格的顺序来，在开发测试阶段，如果你需要频繁地导入、导出测试数据，或者重构表结构，外键约束经常会跳出来“找麻烦”，让你不得不暂时禁用它们，操作完再开启，这个过程有点繁琐。

第三个缺点是,可能导致表之间产生“强耦合”（这是数据库设计层面的一种考量），外键把两张表紧紧地绑在了一起，这意味着，你想删除或修改主表（比如用户表）的某些结构，会变得非常谨慎，因为可能会影响到一堆从表（订单表、地址表等），这种耦合性降低了表的独立性，在某些强调微服务架构、每个服务拥有独立数据库的时代，这种跨表的强约束反而成了障碍。

到底加不加呢？

这真的没有标准答案,完全取决于你的项目情况，你可以这么考虑：

• 如果你的项目是传统的企业内部管理系统（比如OA、ERP）、或者业务逻辑复杂但对并发要求不高的项目，强烈建议加上外键，它能帮你省去很多数据校验的代码，用最低的成本保证最重要的数据安全，性价比极高。
• 如果你的项目是面向海量用户、高并发的互联网应用，追求极致的性能和扩展性，那么可能会倾向于在数据库层面放弃外键，转而通过在应用层编写严谨的业务逻辑代码，来保证数据的一致性，虽然开发难度增加，但换来了更高的灵活性和性能提升空间。
• 一种折中的做法是：在项目开发初期，尤其是初创项目，可以加上外键，因为它能帮助团队快速、稳定地构建模型，避免低级错误，当业务发展到一定规模，确实遇到性能瓶颈时，再考虑有选择地移除某些外键约束，并进行细致的性能优化。

外键是一个强大的工具,但它不是非黑即白的“必选项”或“禁用项”，它的本质是在数据一致性和系统性能/灵活性之间做一个权衡，理解它的优缺点，结合你自己项目的实际需求和未来的发展规划，才能做出最合适的选择。