mysql逻辑删除真的不是⼀个好的设计
转⾃：
在互联⽹公司中数据的积累是⾮常重要的，所以就有了逻辑删除这样的设计。所谓逻辑删除就是在表中加⼊类似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就可以。mysql删除重复的数据保留一条
2. 靠谱⽅案：增加delete_token字段
是的，除了is_deleted字段我们还需要增加⼀个delete_token字段来完成逻辑删除这个设计。定义的⽅式是这样的，delete_token
varchar(32) not null default 'NA'，使⽤⽅式是：⾸先is_deleted字段不再参与unique key，⽽是将delet
e_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的这样的数据库天⽣就是为这些关系设计的，从⽬前来说这些关系当中并不包含删除关系。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。