今天去面试碰到的一个场景题,当时完全没有回答好,于是网上查资料看了下。

前言

不知道大家有没有遇到这么一种业务场景,在业务中有个唯一约束A,当该业务进行逻辑删除后(设置标记为删除状态),再往唯一约束列插入相同的值时,此时会报Duplicate entry,但在业务上,该值时必须要插入的。今天我们就来聊聊处理这种业务场景的几种思路

解决思路

  • 方案一:不采用逻辑删除,直接物理删除
  • 方案二:新建历史表
    主表进行物理删除,同时将删除的记录保存到历史表中
  • 方案三:取消表的唯一约束,同时引入redis来保证唯一约束
    取消表的唯一约束,在项目中引入redis,通过redis来判重,新增时往redis set记录,删除时,删除redis记录
  • 方案四:变更删除标记为时间戳
    将删除状态不以0,1表示,而是以时间戳为值,然后将删除状态为与之前的唯一约束A重新组成唯一联合约束index(A、del_flag),删除时变更del_flag的时间戳
  • 方案五:保留删除标记,同时新建一个字段del_unique_key
    保留删除状态位,再新增一个字段del_unique_key,该字段默认值为0,字段类型和大小与主键id保持一致,同时与原先的唯一约束重新组成联合唯一约束index(A,del_unique_key),业务进行逻辑删除,变更del_unique_key的值为该删除行的主键id

方案的取舍

方案一得从业务的角度上考虑了,如果物理删除,对业务无损,那就无所谓了。

方案二等于需要删除的记录的表都需要有历史表,如果仅仅是用来实现记录删除记录,感觉有点大材小用。

方案三引入redis,虽然也可以解决问题,但是又额外增加复杂度,同时还得保证redis和数据库的一致性。

方案四和方案五其实实现的思路是一样,不过如果已经是在线上跑的业务,还是推荐用第五种方案,毕竟新增字段正常对已有的业务影响相对较小,如果是第四种方案,直接将标志位修改为时间戳,可能还会涉及改业务。

如果是新增业务,第四种和第五种方案比较推荐。

引用自:如何解决逻辑删除与数据库唯一约束冲突


前天遇到了小鹿,昨天是小兔子,今天是你。