为什么数据库不应该使用外键

为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。

当我们想要持久化地存储数据时，使用关系型数据库往往都是最稳妥的选择，这不仅因为今天的关系型数据库种类非常丰富并且稳定，还因为不同社区对关系型数据库的支持都非常完备。我们在前面的文章中曾经分析过 为什么 MySQL 的自增主键不单调也不连续，这篇文章我们来分析关系型数据库中另一个重要的概念 — 外键（Foreign Key）。

在关系型数据库中，外键也被称为关系键，它是关系型数据库中提供关系表之间连接的多个列1，这一组数据列是当前关系表中的外键，也必须是另一个关系表中的候选键（Candidate Key），我们可以通过候选键在当前表中找到唯一的元素2。在通常情况下，我们都会使用关系表中的主键作为其他表中的外键，这样才可以满足关系型数据库对外键的约束。

图 1 - 关系型数据库与外键

外键不仅仅是数据库表中的一个整数，它还提供了额外的一致性保证。因为数据库往往是整个系统的真理之源（Source of Truth），所以保证数据的一致性和正确性非常重要，关系型数据库虽然提供了外键、触发器等特性保证一致性，但是在今天的生产环境中却很少被使用。

引用完整性（Referential Integrity）是数据的属性，如果数据拥有该属性，那么数据中所有的引用都是合法的，在关系型数据库的上下文中，这就意味着关系型数据库中引用另一个表中的值必须存在3。

ALTER TABLE posts
ADD CONSTRAINT FOREIGN KEY (author_id)
REFERENCES authors(id);

上述 SQL 语句可以向关系表中增加外键约束，该 SQL 语句的执行前提是 posts 表中存在 author_id 字段。从 SQL 语句中的 CONSTRAINT 关键字我们也能推测出外键不是一种数据类型，它是不同关系表之间的约束。

图 2 - 无状态服务与数据库

不使用外键的