为什么我会看到这篇文章?

你可能是一个程序员，在简书的搜索框上输入了“数据库逻辑删除解决方案”并点击了搜索按钮。

- 本文章有很多废话，如果不想看直接拉到底部 -

---

我遇到什么问题了？

在进行数据库设计时，你的公司认为数据对于公司来说存在重大意义(即便是已经删除的数据)，因此你被强制要求对于数据的删除只能使用逻辑删除，即增加一个标记字段来记录该数据的删除状态。

你遇到了这样一个场景，你的某个字段需要添加唯一键约束，因此你可能想了个办法，用业务来控制唯一键。例如你的数据表中name是唯一的，现在你需要插入一条name = a的记录：

然而你的服务运行了一段时间后你还是发现了数据库中存在 name = a 且 is_delete = 0 的多条字段，大部分是由于以下原因：

你发现在业务层面这个问题似乎是无法避免的，于是你开始考虑从数据库层面避免该问题。你决定在name字段添加唯一键约束，但很快就否定了这个想法，因为这样根本没法进行删除，所以你开始在网上寻找解决办法。

---

有没有解决这个问题的办法？

百度、谷歌帮帮我。

在网上搜寻很久以后，我看到了简书上一篇比较好的文章：逻辑删除真的不是一个好的设计。该文章提供了三个方法: 1.放弃mysql  2.添加delete_token字段  3.使用数据仓库，评论区机智网友还提出了方法2的改进: 方法2.5。

方法2，即为数据库添加新的一列delete_token，当某一条记录需要删除时，将该字段设置为一个UUID，将name、delete_token设置为唯一键，这样当is_delete=0时，delete_token保持一个默认值，能够有效地限制name唯一，当记录被删除时，由于delete_token是一个唯一的UUID，便能保证删除的记录不会被唯一约束束缚。但正如该文章的博主所说，UUID会占用很大的空间，所以不推荐使用。评论网友针对该问题提出优化对策：方法2.5：将删除记录的delete_token设置为该记录的id。

个人认为，索引太大只是其中一个弊端，该方法还会面临一个很棘手的问题：当需要批量删除时，需要对每一条记录进行逐行删除。例如该表还有一个字段叫age，现在需要删除age > 18的记录，共有50条，在业务中，由于需要为每条的delete_token字段插入一个UUID所以需要将其拆分为50条更新操作来进行。这样的代价显然很难接受

---

我该怎么办？

每种办法都有一定的应用场景，既然强制要求使用逻辑删除，就会面临很多问题，在所难免。今天刚好突然想到一个不错的点子能解决逻辑删除带来的问题，若该方法已经被提出，纯属巧合。

将删除标记设置默认值(例如0)，将唯一字段与删除标记添加唯一键约束。当某一记录需要删除时，将删除标记置为NULL。

由于NULL不会和其他字段有组合唯一键的效果，所以当记录被删除时(删除标记被置为NULL时)，解除了唯一键的约束。此外该方法能很好地解决批量删除的问题(只要置为NULL就完事了)，消耗的空间也并不多(1位 + 联合索引)。

目前还没发现这个办法有什么奇怪的bug。如果有请不要吝啬在评论区留言讨论。