为什么不应该使用数据库外键（重温旧文）

Posted 2020-12-21

为什么不应该使用数据库外键（重温旧文）

导读：最近一篇是否应该使用数据库外键的旧文在国外技术网站HackerNews上引发了热议。文章的作者是一名 GitHub 工程师提出，观点是不应该使用数据库外键。反方的主要观点是互联网开发的经验未必适合企业开发…… 你的观点如何？欢迎留言。GitHub 工程师的原文如下。

在 GitHub，我们从未在任何地方使用外键。

就个人而言，我花了好几年的时间才深入理解外键 FK（Foreign Key）的优劣，在过去的三年中，我一直坚决认为不应使用外键 FK。主要原因是：

• 你实际是用 FK 来拆分数据库，你的应用程序习惯于依靠 FK 来保持完整性，而不是自己代码来完成。它甚至可能依赖于FK来级联删除（发抖）。最终你想来自己来实现数据拆分或者提取时，就需要在不确定的范围内更改和测试该应用程序。

• FK 对性能有影响。他需要索引的开销可能还好，因为大部分情况都需要这些索引，但是为每个插入/删除进行的查找是一项额外开销。

• FK 执行在线 schema 迁移会有问题。

您可能会想到，这最后一颗子弹不是鸡和鸡蛋。FK在可能和不可能之间施加了很多限制。

下面链接有我的一篇旧文章，回顾了 Facebook OSC 首次出现时候的想法，其中包括数据库外键的一些想法：

http://code.openark.org/blog/mysql/mk-schema-change-check-out-ideas-from-oak-online-alter-table

假设您有两个表 P＆C，分别代表 Parent＆Child。C 中有一个外键，因此 C 中的每一行都指向 P 中的某些“父”值。

可以对 C 进行表 schema 迁移操作。但是，由于外键具有唯一的名称，因此新的（迁移的）C 表将具有与原始名称不同的 FK。

对 P 进行表结构修改就会行不通。回想一下用 gh-ost 重命名该表，当重命名表时，FK 将与重命名的表一起移动。要在 ghost 表上创建父级 FK，需要迁移 C；并且因为 gh-ost 使用异步方法，所以 P 和 P-ghost 在任何时间点（锁定时间除外）都不会完全同步，这使得 C 不可能同时拥有 FK 和 P-ghost。一些完整性将被破坏。

mysql 的 pt-online-schema-change 的文档下面还有更多讨论，请参阅
https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html

原文地址：
https://github.com/github/gh-ost/issues/331#issuecomment-266027731

参考阅读：

• 告别烂代码，一文理解微服务中的模式和反模式
• 性能优化怎么做？互联网对象访问频率的91分布原则
• 你不在意的HTTPS证书吊销机制
• 学习区块链必读：如何10分钟搭建Libra

本文作者 Shlomi Noach，为 GitHub 员工，由高可用架构翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式