When a logical deletion encounters a unique index, what are the problems and solutions?

Logical deletion of database

Logical deletion of database , It is relative to physical deletion .
Data is priceless , Once physically deleted , Do not consider passing binlog、 Other technical means , It's hard to get back .
The method of logical deletion is to set a deletion field , We call it is_del, The initial value is 0.
If the user deletes data , We put is_del Field set to 1, In the query , Ignore is_del Field is 1 The data of , Thus, the user perceives that the data has been deleted , But the data still has the effect of database , This is logical deletion .

Conflict between logical deletion and unique index

Imagine a scenario , Data sheet user Of username Fields are unique , That is, the name cannot be duplicated .
To ensure the uniqueness of this field , We are username Add a unique index to the field unique.



At this time, Zhang San registered an account ,username The field is Zhang San .
One day Zhang San cancelled his account , Let's Take Zhang San's data is_del Field set to 1.
But Zhang San came back half a month later , The user name is still registered as Zhang San , However, it prompts that the registration fails .
This is because the unique index retrieves username = Zhang San The record of exists , This obviously does not conform to our daily logic .

Solution

We need to ensure that the logically deleted data does not affect the effect of the unique index .
is_del We no longer only save 0 and 1, Instead, it is modified to the timestamp at the time of deletion , Then create a federated unique index uk(username, is_del).
In this way, even if Zhang San cancels his account many times , Because the time of logical deletion is different , There will be no unique index conflict .