重要的业务数据一般都不会使用物理删除，都是使用一个状态标记deleted实现逻辑删除，但是这种情况下会破坏唯一索引，本位介绍了一些保持唯一索引的方法
除了逻辑删除还有别的替换方案吗？
也可以设计备份表，每次删除的时候，都把数据写入到备份表，并且原始记录使用JSON格式完整保存，然后再删除
- 优点： 原始表不会包含删除的数据，有利于查询效率
- 缺点：实现比较麻烦，每一张需要逻辑删除的表都需要备份表
常见的逻辑删除方案
字段中设置一个字段deleted：0表示未删除，1表示已删除。
但是这种情况，Unique Key会被破坏。假设uk是(user_id, hobby)，用户删除hobby后，就再也无法添加回来了，即使uk是(user_id, hobby, deleted)，用户也无法删除两次。所以还是不能满足要求
推荐方案：多deleted值
- deleted：0代表未删除，其他值代表删除
id | user_id | hobby | deleted |
|---|---|---|---|
1 | 1 | foo | 0 |
2 | 1 | foo | 1 |
3 | 1 | foo | 2 |
这种方式可以保持Unique Key，但是在deleted冲突比较多，需要保证deleted累加
- deleted: 0 代表未删除，删除时把deleted赋值为自增id
id | user_id | hobby | deleted |
|---|---|---|---|
1 | 1 | foo | 0 |
2 | 1 | foo | 2 |
3 | 1 | foo | 3 |
- deleted: 0 代表未删除，删除时把deleted赋值为时间戳
UNIX_TIMESTAMP(NOW())这种方式的好处是，还可以知道删除的时间
参考
- 逻辑删除真的不是一个好的设计
- 逻辑删除情况下设计唯一索引的方案
- 逻辑删除的实现方式？
- 炒冷饭，对于数据库“删除”操作大家平时都是物理删除，还是逻辑删除啊？
