数据库，逻辑删还是物理删？

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

删库跑路

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

删库跑路

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

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

为什么要用逻辑删除？

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

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

利用 binlog 日志

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

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

binlog恢复数据示意图如下：

binlog恢复数据

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

数据库延时同步节点

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

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

写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 t1.is_deleted=1

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

惟一性约束

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

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

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

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

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

由于NULL不会和其他字段有组合唯一键的效果，所以当记录被删除时(删除标记被置为NULL时)，解除了唯一键的约束。此外该方法能很好地解决批量删除的问题(只要置为NULL就完事了)，消耗的空间也并不多(1位 + 联合索引)。
NULL在某些情况下是存在一些问题的，删除时可以将删除标记更新为主键，这样同样保证了唯一约束字段和删除标记组合索引的唯一性。
还可以用另外一种方案，添加一个删除时间delete_time的字段，设置一个不为NULLl的默认值，和惟一字段组成联合唯一索引，当进行逻辑删除的时候同时要更新delete_time,这样同样可以保证惟一性。

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

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

从项目的规模来讲
- 一般的建议是小型系统可以采用物理删除，因为数据恢复的成本，或者说数据的价值，相比较使用逻辑删除的开发、运维付出要少。但是物理删除!=随意删除,要认识到删除操作的风险，重要数据应该设计历史表，删除之前将删除的数据复制到历史表。
- 中大型项目应该采用逻辑删除,有一句话“数据是无价的”。必须承认，在很多时候，数据的价值是远远高于人工的成本的。
从数据价值来讲
- 价值比较高的数据，如电商系统的订单之类的，毫无疑问，一般都是只允许逻辑删除的，及时必须要做物理删除,也要通过备份表、备份日志等方式保证数据可以快速恢复。
- 价值比较低的数据，比如用户操作日志之类，这种数据价值不高，而且数据量很大，在资源有限的情况下，可以考虑物理删除,但是这种危险操作尽量也不要由系统功能去做，而应该由专业的DBA去完成——至于怎么降低DBA操作的风险，大概就得靠制度了。