今天负责的项目，有个重要的表数据被某个同事写的业务代码给delete删除了，导致系统一直报空指针异常告警。然后，运维那边MySQL的bin log设置的没6个小时生成一次，恰巧要等一段时间，客户着急做业务，幸好从阿里云上把数据库某个时间点的数据备份出来查到了被删除的数据，及时补了回来。

       物理删除：指文件存储所用到的磁存储区域被真正的擦除或清零，这样删除的文件是不可以恢复的，物理删除是计算机处理数据时的一个概念。如果在数据库中直接使用delete、drop删除了表数据，如果没有备份的话，数据就很难恢复了。

        逻辑删除（软删除）：逻辑删除就是对要被删除的数据打上一个删除标记，通常使用一个is_deleted字段标示行记录是不是被删除（或者使用一个status字段代表所谓的“删除”状态），在逻辑上是数据是被删除的，但数据本身是依然存在的。

两者的优劣：

       物理删除一定程度上删除了暂时“无用”的数据，降低了表的数据量，对性能肯定是有好处的；但是如果没有备份的话，数据很难恢复。

       逻辑删除恢复的话只要修改is_deleted等类似的状态标示字段就可以了，但是表的数据量肯定会比物理删除增加了，并且查询时经常要考虑到is_deleted字段，对索引都会有影响。

        其实大多数业务场景中，很多“删除”操作对应的都是一个状态，比如商品现在下架了，以后可能还会上架；员工此次离职了，以后说不定还会“二进宫”，又回老东家上班等等，并且数据往往是很有价值的。从目前来看，我本人还是不支持直接使用物理删除，尤其是对业务核心表。其实如果使用物理删除的话，可以把删除的数据放到一个历史表（或者叫日志表）里面去，这样不至于数据完全丢失。像金融证券行业的数据库设计，有的采用交易表和若干张历史表的设计，每天使用数据迁移工具在闲时对闲联机日志表按日期进行转移，如果有关联交易就注意下日切问题同时查联机表和历史表，历史表对更早的数据就通过数据整理规约进数据仓库。不过这种金融证券场景跟主流的互联网场景，个人感觉跟主流的互联网公司的业务场景不是太一致，总之，目前采用逻辑删除的设计还是多一些的吧。

       大家还有什么好的解决方案，欢迎拍砖～～～