本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com

阿里巴巴开发手册还有这么一句话：即使在应用层做了非常完善的校验和控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

需求背景

比如有张用户表, 在插入或者更新数据的时候，我们需要 用户名称(username), 不能重复。

我们首先考虑的是给该字段创建唯一索引

create unique index uni_username on user(username)

似乎这样就可以了，然而事情并没有那么简单。

因为我们表中的数据在删除的时候不会真的的删除，而是采用逻辑删除，会有一个 deleted 字段使用 0，1 标识未删除与已删除。

当然我们可以考虑将 username  + deleted 组合成一个联合唯一索引。

create unique index uni_username_deleted on user(username,deleted)

这样就 ok 了吗？

其实会有一个新的问题，就是如果同一个用户名如果被删除一次。

再去删除会发现系统报错了，因为该条数据已经存在了，不能在删除了。

是不是很多时候因为逻辑删除与唯一索引的冲突，你就不创建唯一索引, 想着自己写的代码自己有信心不会出现脏数据的。

这么想你就太天真啦，数据库是我们最后一道防线, 这道防线都不要了嘛？

阿里巴巴手册有关索引规范，第一条就是

【强制】业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。

手册还有这么一句话：

即使在应用层做了非常完善的校验和控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

所以唯一索引非常有必要！！！

那该怎么做能让逻辑删除与唯一索引兼容？

现在大家比较通用的办法就是

我们依旧可以将 username + deleted 组合成一个联合唯一索引, 但是删除的时候 deleted 不再是固定的 1，而是当前的主键 ID, 也就是 deleted 不等于 0 都是删除状态，如果删除了那 deleted 值 =id 值

既然确立了解决方案, 那就该思考怎么做？

二、MyBatisPlus 逻辑删除

MyBatisPlus 是支持逻辑删除的，如果确定在哪个字段是逻辑删除字段，那就在该字段上添加一个注解

/**     * 1、删除 0、未删除     */    @TableLogic(value = "0", delval = "1")    private Integer deleted;

这个一来操作数据是会自动变成如下:

• 查询时: 查询条件会自动加上 'AND deleted = 0'

• 删除时: 自定添加 'UPDATE SET deleted = 1 … WHERE … AND deleted = 0'

如果你想删除的时候不再是固定 1 而是 id 值, 那么就可以这样改

@TableLogic(value = "0", delval = "id")    private Integer deleted;

如果想改成全局的那么在配置文件中添加

mybatis-plus:  global-config:    db-config:      logic-delete-value: 1 # 逻辑已删除值(默认为 1)      logic-not-delete-value: 0 # 逻辑未删除值(默认为 0)

三、测试

1、用户表

CREATE TABLE `user` (  `id` int unsigned  AUTO_INCREMENT COMMENT '主键',  `username` varchar(128)  COMMENT '用户名',  `phone` varchar(32)  COMMENT '手机号',  `sex` char(1)  COMMENT '性别',  `create_time` datetime  COMMENT '创建时间',  `update_time` datetime  COMMENT '更新时间',  `deleted` tinyint DEFAULT '0' COMMENT '1、删除 0、未删除',  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1

2、创建对应实体

@Data@Accessors(chain = true)@TableName("user")public class UserDO implements Serializable {    private static final long serialVersionUID = 1L;    @TableId(type = IdType.AUTO)    private Integer id;    /**     * 用户名     */    private String username;    /**     * 手机号     */    private String phone;    /**     * 性别     */    private String sex;    /**     * 创建时间     */    private LocalDateTime createTime;    /**     * 更新时间     */    private LocalDateTime updateTime;    /**     * 1、删除 0、未删除     */    private Integer deleted;}

3、物理删除测试

注意: 目前 deleted 字段是没有添加 @TableLogic 注解，同是在全局也没有定义逻辑删除

我们来看下删除示例

@Test    public void deleteById() {        //方式一:根据id删除        mapper.deleteById(10);        //方式二:根据指定字段删除        LambdaQueryWrapper<UserDO> wrapper = new LambdaQueryWrapper<>();        wrapper.eq(UserDO::getSex, "男");        mapper.delete(wrapper);        //方式三:手动逻辑删除        UserDO userDO = new UserDO();        userDO.setId(10);        userDO.setDeleted(1);        mapper.updateById(userDO);    }

执行结果

--方式1DELETE FROM user WHERE id=10--方式2DELETE FROM user WHERE (sex = '男')--方式3UPDATE user SET deleted=1 WHERE id=10

我们通过结果可以看出，如果不添加逻辑删除标识 那删除就是物理删除。

4、逻辑删除测试

我们在 deleted 属性字段 添加 逻辑删除标识

@TableLogic(value = "0", delval = "id") private Integer deleted;

我们再来执行上面三个删除, 看下执行结果

--方式1UPDATE user SET deleted=id WHERE id=10 AND deleted=0--方式2UPDATE user SET deleted=id WHERE deleted=0 AND (sex = '男')--方式3报错了

从执行结果来看，方式一和方式二都从之前的物理删除变成了逻辑删除。

但为什么方式三会报错呢？我们来看下报错的结果

发现问题了, 最终执行的 SQL 竟然是:

UPDATE user  WHERE id=?  AND deleted=0

为什么是这样，正常不应该是

UPDATE user SET deleted=1  WHERE id=?  AND deleted=0

这个就需要去看 Mybatisplus 到底做了什么操作, 改变了我们的 SQL

真相大白了

Mybatisplus 在 updateById 更新时，如果已经加了逻辑删除标记, 那做 SQL 拼接的时候, 会自动过滤掉逻辑删除的 Set 拼接

所以在实际开发中就非常注意，如果你的项目一开始是没有加 Mybatisplus 逻辑删除标识的, 后面你在加逻辑删除标识时，不是说加了就好了。

你还需要考虑对整体项目有没有影响，如果之前是用 updateById 做逻辑删除，那就会导致之前的删除失败甚至是报错，这一点一定要注意。

本人有踩过坑！

求一键三连：点赞、转发、在看。