炒冷饭，对于数据库“删除”操作大家平时都是物理删除，还是逻辑删除啊？
转自：https://www.v2ex.com/t/410612
铺垫
本人不才，不知这个“逻辑删除”词用的对不对，想表达的就是：当删除时只是将 is_deleted 字段设置为 1，而不是真的将这条记录删掉，关键词可能是 logic delete 或 soft delete。
问题
-
查了一些资料，貌似支持“逻辑删除”观点的人是多数的：
-
有前辈提到一个观点，真实世界是没有删除的。订单作废，用户禁用，员工离职，文稿废弃，优惠券作废都是状态的变化。所以 SQL 里面 DELETE 在业务场景里都不应该出现。
-
为了安全，生产环境不能有人或有程序是对数据库的表有 DELETE 权限的。
-
-
反对的声音还是有的：
-
逻辑删除的设计还会导致常用的 unique key 失效（当然用户可将数据行中原来的码和 is_deleted 一起作为 unique key，但是这样又会出现，再次删除时，系统中无法出现两个完全相同的 ID，又都是 is_deleted=1 的记录出现）。
-
被“删除”的这条记录如果在业务中与大量的表有关联关系，那么在删除它时，就会引发很多的级联的更新，或者判断引用并提示用户无法修改正被引用的资源。而要保证这些全部更新无误，又要求事务一定可靠，若产生了状态不一致，那么这些“脏数据”的维护也是很痛苦的。
-
当表中的记录数越来越大时，查询起来会越来越慢。
-
求解
我能理解具体问题需要具体分析，是要“逻辑删除”还是“物理删除”，主要还是要根据实际的业务场景，比如互联网企业搜 /收集的个人信息、电商类平台用户的订单、金融类平台的交易记录，肯定是不能删除的。但是对于一些维护中间状态的数据，如果可以通过记录日志实现“留档”那么就可以真的删掉它。
不知道有没有那种开源组件，可以_自动实现_当我从一个表中物理删除一条记录时，它可以帮我将它转移到备份表中，我看了一个 MySQL 的审计插件，但是好像并不做这个用途的。或者有类似“ commit log ”那种东东，删除时只需要记录一个 log，有需要的时候可以从日志中恢复回来。
参考
下附几个我搜过的资料，希望能帮助和我一样迷茫的童鞋：
-
“别删除数据” http://www.infoq.com/cn/news/2009/09/Do-Not-Delete-Data
-
“逻辑删除真的不是一个好的设计 - 简书” http://www.jianshu.com/p/f37281576585
-
“ MySQL 删除数据是加一个字段做标记，还是将删除的数据插入到另外一张备份表里，哪种方案更好？ - V2EX ”https://fast.v2ex.com/t/406208
-
“不做显式删除，而用 status=0 代替，是好的实践么？ - V2EX ” https://www.v2ex.com/t/363226
