前言
不知道你们有没有遇到这么一种业务场景，在业务中有个惟一约束A，当该业务进行逻辑删除后（设置标记为删除状态），再往惟一约束列插入相同的值时，此时会报Duplicate entry，但在业务上，该值时必需要插入的。今天咱们就来聊聊处理这种业务场景的几种思路redis
解决思路
方案一：不采用逻辑删除，直接物理删除
方案二:新建历史表
主表进行物理删除，同时将删除的记录保存到历史表中数据库
方案三：取消表的惟一约束，同时引入redis来保证惟一约束
取消表的惟一约束，在项目中引入redis，经过redis来判重，新增时往redis set记录，删除时，删除redis记录class
方案四：变动删除标记为时间戳
将删除状态不以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和数据库的一致性。方案四和方案五其实实现的思路是同样，不过若是已是在线上跑的业务，仍是推荐用第五种方案，毕竟新增字段正常对已有的业务影响相对较小，若是是第四种方案，直接将标志位修改成时间戳，可能还会涉及改业务。若是是新增业务，第四种和第五种方案比较推荐项目