1.什么是逻辑删除
所谓逻辑删除是指数据已经“不需要”了，可是并无使用delete语句将这些数据真实的从数据库中物理删除，而只是用一个标志位将其设置为已经删除。
2.为何须要逻辑删除
- 防止数据误删除，不能找回数据；
- 这些数据还具备必定的商业价值，好比用户的注册信息；
- 虽然这些数据能够删除，可是这些数据还有关联数据，这些关联数据不能删除。
对数据进行逻辑删除，能够保证数据的安全性和完整性。可是，逻辑删除也会带来的一些
3.问题：
- 数据库表的数据冗余，致使查询缓慢；
- 写sql进行数据处理时须要排除那些已经逻辑删除的数据，这就会致使sql复杂，容易出错，特别是涉及多表查询时；
- 进行逻辑删除时，还须要考虑与之相关的数据怎么处理；
- 还有，若是数据表的某个字段要求惟一，并强制约束，好比用户表中的登陆用户名字段，设计为逻辑删除的话，一旦有新的同用户名记录就没法插入。但若是不将该字段设置为惟一性约束的，那么在每次插入数据的时候，都需先进行一次查询，看看有无未（逻辑）删除的同名记录存在，低效率是一回事，并且在高并发的系统中，很难保证其正确性。
4.逻辑删除如何设计
设计方案：在表中加一个字段deleted字段（入门级，不推荐）
deleted字段的值为0表示数据未删除，值为1表示数据已经删除。
插入数据数据时，这个值默认为0。删除数据时将这个值设置为1。查询和更新数据时都将‘deleted=0’这个条件带上，只查询和更新没有删除的数据。
这个方案比较简单，可是会有些问题。好比说你表中的一个字段user_name设置了惟一性约束，可是若是你只是进行了逻辑删除的话，相同的user_name就不能进行数据插入了。
问题展示如下：
但若是不将该字段设置为惟一性约束的，那么在每次插入数据的时候，都需先进行一次查询，看看有无未（逻辑）删除的同名记录存在，低效率是一回事，并且在高并发的系统中，很难保证其正确性。
然而你的服务运行了一段时间后你仍是发现了数据库中存在 name = a 且 is_delete = 0 的多条字段，大部分是因为如下缘由(并发问题)：
5.解决思路：
方案一：不采用逻辑删除，直接物理删除
方案二：新建历史表
主表进行物理删除，同时将删除的记录保存到历史表中
方案三：取消表的唯一约束，同时引入redis来保证唯一约束
取消表的唯一约束，在项目中引入redis，通过redis来判重，新增时往redis set记录，删除时，删除redis记录
方案四：保留删除标记，同时新建一个字段delete_token，用UUID
为数据库添加新的一列delete_token，当某一条记录须要删除时，将该字段设置为一个UUID，将name、delete_token设置为惟一键，这样当is_delete=0时，delete_token保持一个默认值，可以有效地限制name惟一，当记录被删除时，因为delete_token是一个惟一的UUID，便能保证删除的记录不会被惟一约束束缚。
方案五：变更删除标记为时间戳
将删除状态不以0,1表示，而是以时间戳为值，然后将删除状态为与之前的唯一约束A重新组成唯一联合约束index（A、del_flag），删除时变更del_flag的时间戳。
方案六：保留删除标记，同时新建一个字段del_unique_key，用主键id 【推荐】
保留删除状态位，再新增一个字段del_unique_key,该字段默认值为0，字段类型和大小与主键id保持一致，同时与原先的唯一约束重新组成联合唯一约束index(A,del_unique_key),业务进行逻辑删除，变更del_unique_key的值为该删除行的主键id。
6.方案的取舍
方案一得从业务的角度上考虑了，如果物理删除，对业务无损，那就无所谓了。方案二等于需要删除的记录的表都需要有历史表，如果仅仅是用来实现记录删除记录，感觉有点大材小用。方案三引入redis，虽然也可以解决问题，但是又额外增加复杂度，同时还得保证redis和数据库的一致性。方案四UUID会占用很大的空间，当需要批量删除时，要对每一条记录进行逐行删除。例如该表还有一个字段叫age，如今须要删除age > 18的记录，共有50条，在业务中，因为须要为每条的delete_token字段插入一个UUID，因此须要将其拆分为50条更新操做来进行。这样的代价显然很难接受。因此不推荐使用。方案五和方案六其实实现的思路是一样，不过如果已经是在线上跑的业务，还是推荐用第六种方案，毕竟新增字段正常对已有的业务影响相对较小，如果是第五种方案，直接将标志位修改为时间戳，可能还会涉及改业务。如果是新增业务，第五种和第六种方案比较推荐。