查看原文
其他

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

Shlomi Noach 高可用架构 2019-11-28

导读:最近一篇是否应该使用数据库外键的旧文在国外技术网站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


参考阅读:


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


高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存