前言
不知道大家有沒有遇到這么一種業務場景，在業務中有個唯一約束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和數據庫的一致性。方案四和方案五其實實現的思路是一樣，不過如果已經是在線上跑的業務，還是推薦用第五種方案，畢竟新增字段正常對已有的業務影響相對較小，如果是第四種方案，直接將標志位修改為時間戳，可能還會涉及改業務。如果是新增業務，第四種和第五種方案比較推薦