数据库,逻辑删还是物理删?

举报
三分恶 发表于 2021/04/19 23:43:04 2021/04/19
【摘要】 相信很多人都听过删库跑路这个词,用搜索引擎检索删库跑路,可以看到很多程序员删库跑路的讨论和新闻。 但是,严格来讲,大部分程序员想删库跑路也做不到。为什么呢?因为没有数据库的删除权限。——真正能删库跑路的是运维,再准确点DBA。 那么平时业务中的删除是怎么做的呢?答案是逻辑删除。 逻辑删除:又名软删除,与物理删除、硬删除相对应,含义是并没有实际的删除数据,只...

相信很多人都听过删库跑路这个词,用搜索引擎检索删库跑路,可以看到很多程序员删库跑路的讨论和新闻。

删库跑路

但是,严格来讲,大部分程序员想删库跑路也做不到。为什么呢?因为没有数据库的删除权限。——真正能删库跑路的是运维,再准确点DBA。

删库跑路

那么平时业务中的删除是怎么做的呢?答案是逻辑删除

逻辑删除:又名软删除,与物理删除、硬删除相对应,含义是并没有实际的删除数据,只是将数据标记已删除(例如增加is_deleted字段)。

为什么要用逻辑删除?

物理删除很好理解,就是真的把数据给删了。

以MySQL为例,假如数据删了,应该怎么恢复呢?主要方式有两种。

利用 binlog 日志

binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。

使用binlog恢复数据,本质上就是通过binlog找到所有DML操作,去掉错误的SQL语句,然后执行其它的SQL语句,就可以将数据恢复。

binlog恢复数据示意图如下:

binlog恢复数据

可以看到,恢复时候不仅需要停掉数据库,假如数据量大的话,去筛选恢复数据sql就😂

数据库延时同步节点

  • 给数据库配置一个同步数据的数据库
  • 同步时间,要延时:比如 1 小时同步一次
  • 当出现问题的时候,只要在这个延时时间内,都还可以恢复出一定的数据

所以,综上,可以认识到,数据删除之后的恢复是要付出很大代价的,而且还存在不可恢复的风险。所以出于安全考虑,生产环境数据库应当尽可能禁止物理删除

逻辑删除会带来什么问题?

数据冗余

这个不用说,数据没有实际删除,自然会产生大量的对业务无用的冗余数据。

增加开发复杂度

写sql进行数据处理时需要排除那些已经逻辑删除的数据,这就会导致sql复杂,容易出错,特别是涉及多表查询时。

例如:

  select t1.name,t2.category from product t1 left join category t2 on t1.category_id=t2.id where t1.is_deleted=1 and t2.is_deleted=1

  
 
  • 1
  • 2
  • 3
  • 4
  • 5

影响惟一性约束

如果数据表的某个字段要求唯一,并强制约束,比如用户表中的登录用户名字段,设计为逻辑删除的话,一旦有新的同用户名记录就无法插入。但如果不将该字段设置为唯一性约束的,那么在每次插入数据的时候,都需先进行一次查询,看看有无未(逻辑)删除的同名记录存在。

惟一性约束

如何设计逻辑删除?

首先需要在表里设计一个删除的标志字段is_deleted

插入数据数据时,这个值默认为0。删除数据时将这个值设置为1。查询和更新数据时都将‘deleted=0’这个条件带上,只查询和更新没有删除的数据。

是不是很简单?但别忘了我们上面提到的影响惟一性约束的问题。这个该怎么解决呢?

可以将唯一约束字段和删除相关的字段创建成组合唯一索引:

  • 将删除标记设置默认值(例如0),将唯一字段与删除标记添加唯一键约束。当某一记录需要删除时,将删除标记置为NULL。

    由于NULL不会和其他字段有组合唯一键的效果,所以当记录被删除时(删除标记被置为NULL时),解除了唯一键的约束。此外该方法能很好地解决批量删除的问题(只要置为NULL就完事了),消耗的空间也并不多(1位 + 联合索引)。

  • NULL在某些情况下是存在一些问题的,删除时可以将删除标记更新为主键,这样同样保证了唯一约束字段和删除标记组合索引的唯一性。

  • 还可以用另外一种方案,添加一个删除时间delete_time的字段,设置一个不为NULLl的默认值,和惟一字段组成联合唯一索引,当进行逻辑删除的时候同时要更新delete_time,这样同样可以保证惟一性。

如果是Java语言开发,推荐MyBatis Plus框架,提供了比较好的逻辑删除支持。

应该用逻辑删除吗?

到现在我们认识到,逻辑删除有利好之处,但是也要付出一定的代价。那么应该用逻辑删除吗?

  • 从项目的规模来讲

    • 一般的建议是小型系统可以采用物理删除,因为数据恢复的成本,或者说数据的价值,相比较使用逻辑删除的开发、运维付出要少。但是物理删除!=随意删除,要认识到删除操作的风险,重要数据应该设计历史表,删除之前将删除的数据复制到历史表。

    • 中大型项目应该采用逻辑删除,有一句话“数据是无价的”。必须承认,在很多时候,数据的价值是远远高于人工的成本的。

  • 从数据价值来讲

    • 价值比较高的数据,如电商系统的订单之类的,毫无疑问,一般都是只允许逻辑删除的,及时必须要做物理删除,也要通过备份表、备份日志等方式保证数据可以快速恢复。

    • 价值比较低的数据,比如用户操作日志之类,这种数据价值不高,而且数据量很大,在资源有限的情况下,可以考虑物理删除,但是这种危险操作尽量也不要由系统功能去做,而应该由专业的DBA去完成——至于怎么降低DBA操作的风险,大概就得靠制度了。



参考:

【1】:逻辑删除实现方案

【2】:逻辑删除还是物理删除

【3】:MySQL 通过 binlog 恢复数据

【4】:使用binlog日志恢复MySQL数据库删除数据的方法

【5】:实现数据逻辑删除的一种方案

【6】:逻辑删除实现方案

文章来源: blog.csdn.net,作者:三分恶,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/sinat_40770656/article/details/115409417

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。