MySQL 删除数据是加一个字段做标记，还是将删除的数据插入到另外一张备份表里，哪种方案更好？

[alvy]

场景和需求

• 现在的业务里，经常有客户需要找回数据。
• 我们从数据统计的角度也需要将删除的数据保留。

方案

• 在表里加一个字段做标记
  优点：“删除”时只需做更新操作
  缺点：已有的大量查询更新等操作需要更改
• 将删除数据插入到另外一张备份表
  优点：代码里只需修改删除部分的代码
  缺点：增加数据库读写操作

请问各位大神，两种方案哪个好？或者是否有其他更优方案？

[whx20202]

我是搞 openstack 的。目前我司就是第一种方案，加了一个 deleted 字段
然后每天运行定时任务，把 deleted 为真的，转移到 shadow_原表名中

shadow 系的表，每天也运行定时任务，超过很久的就删除

有好有坏吧
一个重大的坏处就是查询时候， 动不动就得加上 deleted=0，然后大部分都是没删的么，优化器在索引上就吃了很多亏

[master13]

拍脑袋一想当然是加一个字段。但是严谨点也要具体看应用场景，比如你这个表记录巨多(比如>1 亿条），并且索引下也不是很效率；再比如你这个表特别稀疏等等……这种特殊场景下，应该有更好的选择。

[alvy]

@whx20202 不用定时任务，删除的时候就插入备份表里会开销很大吗？

[whx20202]

@alvy 删除的时候就插入备份表肯定是有影响的，不过按我理解影响没那么大

有的人在触发器里面做，有的人在代码事务里面做，有不少的区别，但也都是小点

如果你们删除（删除 + 转移添加）时延要求苛刻，而且还高并发，那就得权衡一下了

[whypool]

现有数据表的设计都不会物理删除，只是逻辑删除；
已经标记删除是数据定期备份，比如一季度或者一个月，这个看数据量；
至于性能，如果要求高可以上缓存

[crazyneo]

绝大部分金融行业数据库相关系统早就有过完整的解决方案了，不要拍脑袋学什么 NoSQL 搞什么 tombstone 之类，就是交易日志表两张每天切换，历史表若干张保存 180 天，自己写个或者用开源的数据迁移工具在闲时对闲联机日志表按日期进行转移，如果有关联交易就注意下日切问题同时查联机表和历史表，历史表对超过 180 天的数据就通过数据整理规约进数据仓库，最后对两年以上的交易上磁带，频率大概是 2-3 天一次。

[alvy]

@whx20202 删除是一个低频操作，这样看来，第二种方案更方便

[alvy]

@whypool 请问您说的缓存的逻辑是什么

[alvy]

@crazyneo 高端，不过我们的业务和数据量现在应该用不到

[lusyoe]

加字段，加个视图判断字段即可

[owenliang]

用软删除最大的问题就是查询效率更差了，走其他索引过滤 deleted 字段，如果删除量很大，那么查询效率肯定很 low，是个矛盾。

[openbsd]

这个问题很常见啊，个人观点
表里行数少（忘了数据来自哪<500W 行）话，第一个方法即可，简单粗暴
>一亿行的，你会发现第二种方法会好很多