0
点赞
收藏
分享

微信扫一扫

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

尤克乔乔 2022-01-31 阅读 158


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

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

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

数据库,逻辑删还是物理删?_字段_02

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

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

为什么要用逻辑删除?

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

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

利用 binlog 日志

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

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

binlog恢复数据示意图如下:

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

可以看到,恢复时候不仅需要停掉数据库,假如数据量大的话,去筛选恢复数据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

影响惟一性约束

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

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

如何设计逻辑删除?

首先需要在表里设计一个删除的标志字段​​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】:​​逻辑删除实现方案​​



举报

相关推荐

0 条评论