0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看威廉希尔官方网站 视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

数据库不使用外键的原因是什么

数据分析与开发 来源:CSDN博客 作者:CSDN博客 2020-10-12 14:07 次阅读

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

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

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

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

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

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

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

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

不使用外键的原因其实很简单,MySQL、PostgreSQL 等关系型数据库很难水平扩容,但是无状态的服务往往都可以很容易地扩容。由于外键等特性需要数据库执行额外的工作,而这些操作会占用数据库的计算资源,所以我们可以将大部分的需求都迁移到无状态的服务中完成以降低数据库的工作负载。

根据更新和删除时的行为不同,我们可以将外键分成RESTRICT、CASCADE和SET NULL等几种[^4],当我们为关系表中的字段增加外键约束时,需要指定外键的类型,最常见的也就是RESTRICT和CASCADE两种,其中RESTRICT为外键的默认类型,不同类型的外键会带来不同的额外开销,而这些额外开销就是我们不使用外键的理由:

使用RESTRICT会在更新或者删除记录时对外键对应的记录是否存在进行一致性检查;

使用CASCADE会在更新或者删除记录时触发级联更新或者删除操作;

注意:MySQL 中的NO ACTION和RESTRICT具有相同的语义[^5]。

接下来我们会详细介绍关系型数据库如何处理上述两种不同类型的外键,而我们应该如何在应用中模拟这些功能。

一致性检查

当我们使用默认的外键类型RESTRICT时,在创建、修改或者删除记录时都会检查引用的合法性。想要在 MySQL 等数据库中触发外键的一致性检查其实非常容易,假设我们的数据库中包含posts(id, author_id, content)和authors(id, name)两张表,在执行如下所示的操作时都会触发数据库对外键的检查:

向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-8 3770 309503 ns/opBenchmarkForeignKey-8 3331 317162 ns/op BenchmarkBaseline-8 3192 315506 ns/opBenchmarkForeignKey-8 3381 315577 ns/op BenchmarkBaseline-8 3298 312761 ns/opBenchmarkForeignKey-8 3829 345342 ns/op BenchmarkBaseline-8 3753 291642 ns/opBenchmarkForeignKey-8 3948 325239 ns/op

作者执行了 4 次外键的基准测试,虽然 4 次测试的结果不是特别稳定,但是使用外键的用例在每次测试中都明显弱于不使用外键的用例,外键带来的额外开销分别为 ~2.47%、~0.02%、~10.41% 和 ~11.52%。这里的基准测试只是一个比较简单的定量分析,但是我们也可以从结果中看到大概的趋势 — 外键的完整性检查确实会带来额外的性能开销,而这些开销在高并发的服务中需要慎重考虑。

想要在应用程序中interwetten与威廉的赔率体系 数据库外键的功能其实比较容易,我们只需要遵循以下的几个准则:

向表中插入数据或者修改表中的数据时,都应该执行额外的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;

当客户端更新authors表中记录的主键时,数据库会同时更新posts表中所有引用该记录的外键;

当客户端删除authors表中的记录时,数据库会删除所有与authors表关联的记录;

不过无论是执行更新还是删除操作,数据库都可以保证各个关系表之间引用的一致性和合法性不会出现引用到不存在记录的情况,与RESTRICT行为一样,所有外键的更新和删除行为都可以通过执行额外的检查和操作保证数据的一致。

图 4 - 复杂的级联操作

虽然级联删除的出发点也是保证数据的完整性,但是在设计关系表之间的不同关系时,我们也需要注意级联删除引起的数据大规模删除的问题。如上图所示,当客户端想要在数据库中删除authos表中的数据时,如果我们同时在authors和posts中指定了级联删除的行为,那么数据库会同时删除所有关联的posts记录以及与posts表关联的comments数据。

这种涉及多级的级联删除行为在数据量较小的数据库中不会导致问题,但是在数据量较大的数据库中删除关键数据可能会引起雪崩,一条记录的删除可能会被放大到几十倍甚至上百倍,这些对磁盘的随机读写会带来巨大的开销,是我们想要尽可能避免的情况。如果我们能够较好地设计各个表之间的关系并且慎用CASCADE行为,这对于保证数据库中数据的合法性有着很重要的意义,使用该特性可以避免数据库中出现过期的、不合法的数据,但是在使用时也要合理预估可能造成的最坏情况。

手动实现数据库的级联删除操作是可行的,如果我们在一个事务中按照顺序删除所有的数据,确实可以保证数据的一致性,但是这与外键的级联删除功能没有太大的区别,反而会有更差的表现。如果我们能够接受在一个时间窗口内的数据不一致,就可以将一个大号的删除任务拆成多个子任务分批执行,降低对数据库影响的峰值。

DELETE FROM posts WHERE author_id = 1 LIMIT 100;DELETE FROM posts WHERE author_id = 1 LIMIT 100;...DELETE FROM authors WHERE id = 1;

与数据库外键的CASCADE相比,这种方式会带来更大的额外开销,只是我们能降低对数据库性能的瞬时影响。

总结

外键提供的几种在更新和删除时的不同行为都可以帮助我们保证数据库中数据的一致性和引用合法性,但是外键的使用也需要数据库承担额外的开销,在大多数服务都可以水平扩容的今天,高并发场景中使用外键确实会影响服务的吞吐量上限。在数据库之外手动实现外键的功能是可能的,但是却会带来很多维护上的成本或者需要我们在数据一致性上做出一些妥协。我们可以从可用性、一致性几个方面分析使用外键、模拟外键以及不使用外键的差异:

不使用外键牺牲了数据库中数据的一致性,但是却能够减少数据库的负载;

模拟外键将一部分工作移到了数据库之外,我们可能需要放弃一部分一致性以获得更高的可用性,但是为了这部分可用性,我们会付出更多的研发与维护成本,也增加了与数据库之间的网络通信次数;

使用外键保证了数据库中数据的一致性,也将全部的计算任务全部交给了数据库;

在大多数不需要高并发或者对一致性有较强要求的系统中,我们可以直接使用数据库提供的外键帮助我们对数据进行校验,但是在对一致性要求不高的、复杂的场景或者大规模的团队中,不使用外键也确实可以为数据库减负,而大团队也有更多的时间和精力去设计其他的方案,例如:分布式的关系型数据库。

当我们考虑应不应该在数据库中使用外键时,需要关注的核心我们的数据库承担这部分计算任务后会不会影响系统的可用性,在使用时也不应该一刀切的决定用或者不用外键,应该根据具体的场景做决策,我们在这里介绍了两个使用外键时可能遇到的问题:

RESTRICT外键会在更新和删除关系表中的数据时对外键约束的合法性进行检查,保证外键不会引用到不存在的记录;

CASCADE外键会在更新和删除关系表中的数据时触发对关联记录的更新和删除,在数据量较大的数据库中可能会有数量级的放大效果;

我们在很多时候其实并不能选择是否使用外键,大多数公司的 DBA 都会对数据库系统的使用有比较明确的规定,但是我们要清楚做出使用外键和不使用外键这一抉择的原因。到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题:

数据库中还有哪些特性是我们在生产环境中不会使用的?为什么?

分布式的关系型数据库与 MySQL 等传统数据库有哪些区别?

责任编辑人:CC

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 数据库
    +关注

    关注

    7

    文章

    3795

    浏览量

    64367

原文标题:为什么数据库不应该使用外键

文章出处:【微信号:DBDevs,微信公众号:数据分析与开发】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    数据库数据恢复—Mysql数据库表记录丢失的数据恢复流程

    Mysql数据库故障: Mysql数据库表记录丢失。 Mysql数据库故障表现: 1、Mysql数据库表中无任何数据或只有部分
    的头像 发表于 12-16 11:05 123次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—Mysql<b class='flag-5'>数据库</b>表记录丢失的<b class='flag-5'>数据</b>恢复流程

    数据库事件触发的设置和应用

    数据库无论对于生产管理还是很多的实际应用都非常重要。小编这次聊一下数据库事件触发的应用。示例使用了postgresql和Python。
    的头像 发表于 12-13 15:14 112次阅读

    数据库数据恢复—MYSQL数据库ibdata1文件损坏的数据恢复案例

    mysql数据库故障: mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库
    的头像 发表于 12-09 11:05 144次阅读

    Sybase数据恢复—Sybase数据库无法启动怎么恢复数据

    数据库数据恢复工程师经过检测,发现Sybase数据库出现故障的原因是:异常断电造成Sybase数据库无法回写正常
    的头像 发表于 11-30 16:45 114次阅读
    Sybase<b class='flag-5'>数据</b>恢复—Sybase<b class='flag-5'>数据库</b>无法启动怎么恢复<b class='flag-5'>数据</b>?

    LS10串口数据库模块扩SD卡功能

    LS10串口数据库模块扩SD卡功能
    的头像 发表于 11-23 09:42 190次阅读
    LS10串口<b class='flag-5'>数据库</b>模块<b class='flag-5'>外</b>扩SD卡功能

    数据库数据恢复—通过拼接数据库碎片恢复SQLserver数据库

    一个运行在存储上的SQLServer数据库,有1000多个文件,大小几十TB。数据库每10天生成一个NDF文件,每个NDF几百GB大小。数据库包含两个LDF文件。 存储损坏,数据库
    的头像 发表于 10-31 13:21 203次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—通过拼接<b class='flag-5'>数据库</b>碎片恢复SQLserver<b class='flag-5'>数据库</b>

    Oracle数据恢复—异常断电后Oracle数据库报错的数据恢复案例

    Oracle数据库故障: 机房异常断电后,Oracle数据库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据
    的头像 发表于 09-30 13:31 299次阅读
    Oracle<b class='flag-5'>数据</b>恢复—异常断电后Oracle<b class='flag-5'>数据库</b>启<b class='flag-5'>库</b>报错的<b class='flag-5'>数据</b>恢复案例

    数据库数据恢复—Oracle数据库文件system01.dbf损坏的数据恢复案例

    打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。
    的头像 发表于 09-21 14:25 323次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—Oracle<b class='flag-5'>数据库</b>文件system01.dbf损坏的<b class='flag-5'>数据</b>恢复案例

    数据库数据恢复—SQL Server数据库出现823错误的数据恢复案例

    SQL Server数据库故障: SQL Server附加数据库出现错误823,附加数据库失败。数据库没有备份,无法通过备份恢复数据库
    的头像 发表于 09-20 11:46 338次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—SQL Server<b class='flag-5'>数据库</b>出现823错误的<b class='flag-5'>数据</b>恢复案例

    数据库数据恢复—SqlServer数据库底层File Record被截断为0的数据恢复案例

    SQL Server数据库数据无法被读取。 经过数据库数据恢复工程师的初步检测,发现SQL Server数据库文件无法被读取的
    的头像 发表于 07-26 11:27 379次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—SqlServer<b class='flag-5'>数据库</b>底层File Record被截断为0的<b class='flag-5'>数据</b>恢复案例

    恒讯科技分析:sql数据库怎么用?

    SQL数据库的使用通常包括以下几个基本步骤: 1、选择数据库系统: 选择适合您需求的SQL数据库系统,如MySQL、PostgreSQL、Microsoft SQL Server、SQLite等
    的头像 发表于 07-15 14:40 347次阅读

    数据库数据恢复—SQL Server数据库所在分区空间不足报错的数据恢复案例

    SQL Server数据库数据恢复环境: 某品牌服务器存储中有两组raid5磁盘阵列。操作系统层面跑着SQL Server数据库,SQL Server数据库存放在D盘分区中。
    的头像 发表于 07-10 13:54 481次阅读

    数据库数据恢复—raid5阵列上层Sql Server数据库数据恢复案例

    数据库故障: 数据库文件丢失,主要涉及3个数据库,数千张表。数据库文件丢失原因未知,不能确定丢失的
    的头像 发表于 05-08 11:43 505次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—raid5阵列上层Sql Server<b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复案例

    数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例

    。存储空间LUN划分了两个逻辑分区。 服务器故障&初检: 由于未知原因,Sql Server数据库文件丢失,丢失数据涉及到3个,表的数量有3000左右。
    的头像 发表于 04-11 15:38 883次阅读
    <b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复—Sql Server<b class='flag-5'>数据库</b>文件丢失的<b class='flag-5'>数据</b>恢复案例

    数据库数据恢复】Oracle数据库ASM实例无法挂载的数据恢复案例

    oracle数据库ASM磁盘组掉线,ASM实例不能挂载。数据库管理员尝试修复数据库,但是没有成功。
    的头像 发表于 02-01 17:39 519次阅读
    【<b class='flag-5'>数据库</b><b class='flag-5'>数据</b>恢复】Oracle<b class='flag-5'>数据库</b>ASM实例无法挂载的<b class='flag-5'>数据</b>恢复案例