一、什么是伪删除？
在数据库设计时，通常会遇到删除数据的情况；一般删除的方式包括：物理删除跟逻辑删除。
- 逻辑删除：看上去是删除了，但实际上却没有删除，仅对相应的记录做标识，用于表示其已经被删除，一般会在记录上增加一个 is_deleted 字段，默认值为0，表示未被删除的数据，为1，则表示该数据被删除了。
- 物理删除：在数据库中不再存储该数据，在软件层面无法恢复该数据。
二、为什么要用伪删除？
在产品、项目被实施部署后，会发生多种情况导致数据被删除掉，如果仅采用物理删除，会导致数据无法恢复，可能会造成严重后果。
导致数据被删除的情况包括：
- 软件bug：软件可能存在逻辑性bug，本不应该删除的时候执行了删除。
- 使用者的误操作：使用者未按规定执行删除操作。
三、伪删除的设计经验分享
3.1 遇见过的删除情况
- 在一个内容管理系统中，有栏目表、文章表，一篇文章属于一个栏目。在删除一个栏目的时候执行了伪删除，同时把关联的文章物理删除了，造成客户数据丢失。最终通过回滚服务器快照找回数据。
服务器快照很重要！！！
服务器快照很重要！！！
服务器快照很重要！！！
重要的话要说三遍！
- 客户在操作数据时，也不管删除时强制提醒的时候提醒的是什么，一下子就把数据删除了，等过后反映过来了就联系公司，想恢复数据。好在这部分有伪删除的设计。
3.2 设计伪删除避坑经验
经验：删除标识不要与业务状态共用一个
之前在设计伪删除的时候出现过这样的问题：将伪删除标识与业务状态设置为一个属性。
比如：一篇文章有个状态（status）字段，分别有：草稿箱、待发布、已上线、已下线、已删除。
一般情况下这样的设计也不会出现太大的问题，因为删除状态与其他状态是互斥的，要么是删除的文章，要么是其他状态的文章。
后来遇到了这样一个情况，导致出现问题了。
前面也说了，在删除文章所属栏目的时候会将该栏目下的文章都标识为删除状态（最早是直接物理删除），但是，当删除文章栏目这个操作是误操作，这个时候要恢复的话就没法维护了。
【恢复步骤】：
- 将栏目的伪删除标识设置为0，栏目恢复；
- 找到所有归属于该栏目的文章，并将文章恢复到原来的状态。
在执行到第二步的时候出现了问题，原来该栏目的文章状态，可能有：待发布，已上线，已删除等等。在执行删除栏目操作后，对应的文章都变成了【已删除】状态，所以无法还原到原来的状态下。
所以，正确的方式是将伪删除标识与业务状态分离开来。