标签：联系我们 修改 check 创建 性能优化 代码 优化 访问 翻译
为什么不应该使用数据库外键（重温旧文）导读：最近一篇是否应该使用数据库外键的旧文在国外技术网站HackerNews上引发了热议。文章的作者是一名 GitHub 工程师提出，观点是不应该使用数据库外键。反方的主要观点是互联网开发的经验未必适合企业开发…… 你的观点如何？欢迎留言。GitHub 工程师的原文如下。
在 GitHub，我们从未在任何地方使用外键。
就个人而言，我花了好几年的时间才深入理解外键 FK（Foreign Key）的优劣，在过去的三年中，我一直坚决认为不应使用外键 FK。主要原因是：
你实际是用 FK 来拆分数据库，你的应用程序习惯于依靠 FK 来保持完整性，而不是自己代码来完成。它甚至可能依赖于FK来级联删除（发抖）。最终你想来自己来实现数据拆分或者提取时，就需要在不确定的范围内更改和测试该应用程序。
FK 对性能有影响。他需要索引的开销可能还好，因为大部分情况都需要这些索引，但是为每个插入/删除进行的查找是一项额外开销。
您可能会想到，这最后一颗子弹不是鸡和鸡蛋。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 员工，由高可用架构翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
标签：联系我们 修改 check 创建 性能优化 代码 优化 访问 翻译
原文地址：https://blog.51cto.com/14977574/2546373
