在互联网公司中数据的积累是非常重要的，所以就有了逻辑删除这样的设计。所谓逻辑删除就是在表中加入类似is_deleted字段，将删除操作变成更新操作。当is_deleted=1时就代表这条记录已经删除，这样做的好处非常明显，数据不会消失，对于商业分析来说“被删除”的数据也非常有价值。
但事情往往不会这么简单，硬币的另一面是逻辑删除引入了一点点复杂度，大部分读操作都需要过滤掉处于删除状态的记录，过滤操作要么在数据库层面完成，要么在应用中完成，通常这样的复杂度是完全可以接受的，但是对于MySQL而言，逻辑删除的设计还会导致常用的unique key失效，原因非常简单，已经删除的数据仍然存在，所以在设计unique key的时候程序员不得不将is_deleted字段与应用要求unique的字段一起放入unique key中，这样is_deleted=0的记录就不会与is_deleted=1的字段冲突了，这是符合逻辑的，is_deleted=0的记录之间会发生冲突，但这正是unique key的本意，所以也是符合逻辑的，但是问题在于is_deleted=1的记录之间也会发生冲突，这可能就不符合逻辑了，为什么呢？简单来说这样的设计在unique key存在的情况下不允许unique key字段相同的记录被删除两次以上，这对于应用来说是一个很大的限制。
而实际上很多互联网公司在数据库设计规范中都加入了逻辑删除的强制规定，从商业分析的角度来说这样做没有问题，但问题留给了开发人员，我们只能在unique key与逻辑删除之间做一个排他的选择吗？但是unique key都放弃了，我们用的还是关系型数据库吗？不过两者都兼得的办法还是有的，我个人认为有三种方案，依次是1不靠谱方案，2靠谱方案，3推荐方案
1. 不靠谱方案：放弃使用MySQL
朋友们，看完这个小标题你完全可以选择跳过这一段。
但为什么说这样可以解决问题呢，因为我们需要的其实是这样一个功能：unique key where is_deleted=0，对吗？我们其实不关心is_deleted=1的记录是否重复，遗憾的是MySQL并不支持这个功能，但是并非所有的数据库都不支持这个功能，比如SQL Server就可以。
2. 靠谱方案：增加delete_token字段
是的，除了is_deleted字段我们还需要增加一个delete_token字段来完成逻辑删除这个设计。定义的方式是这样的，delete_token varchar(32) not null default 'NA'，使用方式是：首先is_deleted字段不再参与unique key，而是将delete_token加入unique key中，在删除时，is_deleted字段更新成1，同时delete_token字段更新成一个32位的uuid，这样删除的记录因为uuid的存在就不会冲突了，问题解决了。但为什么我不推荐使用这个方案呢？因为MySQL对于unique key的长度是有限制的，对于InnoDB来说这个限制是767 bytes， 对于MyISAM这个限制是1000 bytes，假设你使用了utf8mb4 字符编码，那么delete_token就会占据128 bytes，这其实引入了另一个隐含的限制。
3. 推荐方案： 使用数据仓库
回到逻辑删除的初衷，我们需要的是将数据沉淀下来用于商业分析，而逻辑删除的设计将数据分析与应用逻辑杂糅在了一起，而实际上应用使用的MySQL并不适合做数据分析，又平白增加了应用的复杂度，这样的设计最终两头都不讨好。所以还是让应用数据库与数据仓库发挥各自的功能吧，应用数据库与数据仓库都可以通过监听数据操作指令来自由的更新数据，至于删除操作，对于应用数据库来说就是物理删除，但对于数据仓库来说可以只是一条更新操作。
总结：
为什么我们要使用MySQL这样的数据库呢？因为我们关心的不止是数据本身还有数据之间的关系，而MySQL的这样的数据库天生就是为这些关系设计的，从目前来说这些关系当中并不包含删除关系。
