江苏龙网

  1. 首页 > 人文 > >

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


  • 向 posts 表中插入数据时 ， 检查 author_id 是否在 authors 表中存在；
  • 修改 posts 表中的数据时 ， 检查 author_id 是否在 authors 表中存在；
  • 删除 authors 表中的数据时 ， 检查 posts 中是否存在引用当前记录的外键；
作为专门用于管理数据的系统 ， 数据库与应用服务相比能够更好地保证完整性 ， 而上述的这些操作都是引入外键带来的额外工作 ， 不过这也是数据库保证数据完整性的必要代价 。 上述的这些分析都是理论上的定性分析 ， 我们其实可以简单的定量分析一下引入外键对性能的影响 。
在这里我们在数据库中同时创建 authors、posts 和 foreign_key_posts 三种表 ， 如下所示 ， 其中 posts 和 foreign_key_posts 两个表中的列完全相同 ， 只是 foreign_key_posts 表为 author_id 字段增加了 RESTRICT 类型的外键约束：
数据库为什么数据库不应该使用外键
本文插图
图 3 - 外键性能测试关系图
我们先在 authors 表中插入一条记录 ， 随后分别在 posts 和 foreign_key_posts中插入多条新数据列引用该条记录 ， 前者不会检查外键的合法性 ， 而后者会做额外的检查 。 你可以在 这里 找到作者用来测试外键额外开销的 Go 语言代码6 ， 经过多次基准测试 ， 我们可以得到如下所示的结果：
BenchmarkBaseline-83770309503 ns/opBenchmarkForeignKey-83331317162 ns/opBenchmarkBaseline-83192315506 ns/opBenchmarkForeignKey-83381315577 ns/opBenchmarkBaseline-83298312761 ns/opBenchmarkForeignKey-83829345342 ns/opBenchmarkBaseline-83753291642 ns/opBenchmarkForeignKey-83948325239 ns/op 作者执行了 4 次外键的基准测试 ， 虽然 4 次测试的结果不是特别稳定 ， 但是使用外键的用例在每次测试中都明显弱于不使用外键的用例 ， 外键带来的额外开销分别为 ~2.47%、~0.02%、~10.41% 和 ~11.52% 。 这里的基准测试只是一个比较简单的定量分析 ， 但是我们也可以从结果中看到大概的趋势 — 外键的完整性检查确实会带来额外的性能开销 ， 而这些开销在高并发的服务中需要慎重考虑 。
想要在应用程序中模拟数据库外键的功能其实比较容易 ， 我们只需要遵循以下的几个准则：
  • 向表中插入数据或者修改表中的数据时 ， 都应该执行额外的 SELECT 语句确保它引用的数据在数据库中存在；
  • 在删除数据之前需要执行额外的 SELECT 语句检查是否存在当前记录的引用；
需要注意的是为了保证一致性 ， 我们需要在事务中执行上述的查询和修改语句 ， 这样才能完整模拟外键的功能；当我们向 posts 表中插入或者修改数据时 ， 需要的处理相对比较简单 ， 我们只需要执行有限的 SELECT 语句并按照如下所示的模式执行对应的操作就可以了：
BEGINSELECT * FROM authors WHERE id =FOR UPDATE;-- INSERT INTO posts ... / UPDATE posts ...END 但是如果我们要删除 authors 表中的数据 ， 就需要查询所有引用 authors 数据的表；如果有 10 个表都有指向 authors 表的外键 ， 我们就需要在 10 个表中查询是否存在对应的记录 ， 这个过程相对比较麻烦 ， 不过也是为了实现完整性的必要代价 ， 不过这种模拟外键方法其实远比使用外键更消耗资源 ， 它不仅需要查询关联数据 ， 还要通过网络发送更多的数据包 。
级联操作 当我们在关系型数据库中创建外键约束时 ， 如果使用如下所示的 SQL 语句指定更新或者删除记录时使用 CASCADE 行为 ， 那么在客户端更新或者删除数据时就会触发级联操作：
ALTER TABLE postsADD CONSTRAINT FOREIGN KEY (author_id)REFERENCES authors(id)ON UPDATE CASCADEON DELETE CASCADE;


推荐阅读


上一篇：华为公司扒鸡店打出：苹果手机购买恕不接待，华为手机结账满减二十。

下一篇：美团网没事没事！我们还是能同时用两个软件叫车的