MyBatis-Plus DML与乐观锁

淡淡的烟草味﹌ 2024-05-23 18:56 50阅读 0赞

![168c1abc67f4402ebfc99ff077a3e4da.gif][]

> 哈喽~大家好，这篇来看看MyBatis-Plus DML与乐观锁。
> 
> ?个人主页：[个人主页][Link 1]
> 
> ? 系列专栏： [【Java框架】 ][Java_]
> 
> ?与这篇相关的文章：
> 
> <table> 
>  <tbody> 
>   <tr> 
>    <td>Springboot 整合与文件配置</td> 
>    <td><a href="https://blog.csdn.net/aasd23/article/details/127627590" title="Springboot 整合与文件配置_程序猿追的博客-CSDN博客" rel="nofollow">Springboot 整合与文件配置_程序猿追的博客-CSDN博客</a></td> 
>   </tr> 
>   <tr> 
>    <td>springboot 项目起步讲解及自动装配原理</td> 
>    <td><a href="https://blog.csdn.net/aasd23/article/details/127583044" title="springboot 项目起步讲解及自动装配原理_程序猿追的博客-CSDN博客" rel="nofollow">springboot 项目起步讲解及自动装配原理_程序猿追的博客-CSDN博客</a></td> 
>   </tr> 
>   <tr> 
>    <td>MyBatis-Plus介绍与项目起步讲解</td> 
>    <td><a href="https://blog.csdn.net/aasd23/article/details/127758263?spm=1001.2014.3001.5501" title="MyBatis-Plus介绍与项目起步讲解_程序猿追的博客-CSDN博客" rel="nofollow">MyBatis-Plus介绍与项目起步讲解_程序猿追的博客-CSDN博客</a></td> 
>   </tr> 
>  </tbody> 
> </table>

**目录**

一、前言

二、id生成策略控制

三、雪花算法

四、ID生成策略对比

五、多记录操作

六、乐观锁

1、概念

2、实现思路

3、实现步骤

--------------------

## 一、前言 ##

查询相关的操作我们已经介绍完了，紧接着我们需要对另外三个，增删改进行内容的讲解。挨个来说明下，首先是新增(insert)中的内容。

## 二、id生成策略控制 ##

前面我们在新增的时候留了一个问题，就是新增成功后，主键ID是一个很长串的内容，我们更想要的是按照数据库表字段进行自增长，在解决这个问题之前，我们先来分析下ID该如何选择:

**不同的表应用不同的id生成策略**

> **日志：**自增（1,2,3,4，……）
> 
> **购物订单：**特殊规则（FQ23948AK3843）
> 
> **外卖单：**关联地区日期等信息（10 04 20200314 34 91）
> 
> **关系表：**可省略id
> 
> 不同的业务采用的ID生成方式应该是不一样的，那么在MP中都提供了哪些主键生成策略，以及我们该如何进行选择?
> 
> 在这里我们又需要用到MP的一个注解叫`@TableId`

**知识点1：@TableId**

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>@TableId</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>类型</td> 
   <td>属性注解</td> 
  </tr> 
  <tr> 
   <td>位置</td> 
   <td>模型类中用于表示主键的属性定义上方</td> 
  </tr> 
  <tr> 
   <td>作用</td> 
   <td>设置当前类中主键属性的生成策略</td> 
  </tr> 
  <tr> 
   <td>相关属性</td> 
   <td>value(默认)：设置数据库表主键名称 type:设置主键属性的生成策略，值查照IdType的枚举值</td> 
  </tr> 
 </tbody> 
</table>

**实体类的字段上加上 @TableId(type = IdType.AUTO)**

@Data
    //设置表名映射关系
    @TableName("user")
    public class User {
        //设置主键生成策略
    //    @TableId(type = IdType.ASSIGN_ID)
        @TableId(type = IdType.AUTO)
        private Long id;
        private String name;
        @TableField(value = "password",select = false)
        private String password;
        private Integer age;
        private String tel;
        @TableField(exist = false)
        private Integer online;
        //逻辑删除字段，标记当前记录是否被删除
    //    @TableLogic(value = "0" ,delval = "1")
        private Integer deleted;
        @Version
        private Integer version;
    }

**测试类**

@Test
        void testSave(){
            User user = new User();
    //        user.setId(667L);
            user.setName("只因");
            user.setPassword("666");
            user.setAge(12);
            user.setTel("1231231231");
            userDao.insert(user);
        }

![85e2fb30c7bb4d09a338cc3b1f893177.png][]

**设置id自增长值**

![4d719f0362654fdab4d090b1099ad415.png][]

在 @TableId(type = IdType.AUTO) 里面的AUTO是自增长之外还有如下几种生成策略:

> **NONE:** 不设置id生成策略
> 
> **INPUT:**用户手工输入id
> 
> **ASSIGN\_ID:**雪花算法生成id(可兼容数值型与字符串型)
> 
> **ASSIGN\_UUID**:以UUID生成算法作为id生成策略
> 
> 其他的几个策略均已过时，都将被ASSIGN\_ID和ASSIGN\_UUID代替掉。

**分布式ID是什么?**

> 当数据量足够大的时候，一台数据库服务器存储不下，这个时候就需要多台数据库服务器进行存储，比如订单表就有可能被存储在不同的服务器上，如果用数据库表的自增主键，因为在两台服务器上所以会出现冲突，这个时候就需要一个全局唯一ID,这个ID就是分布式ID。

## 三、**雪花算法** ##

雪花算法(SnowFlake),是Twitter官方给出的算法实现 是用Scala写的。其生成的结果是一个64bit大小整数，它的结构如下图:

![206590b560624714bc2d43c6fb20841d.png][]

> 1.  1bit,不用,因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。
> 2.  41bit-时间戳，用来记录时间戳，毫秒级
> 3.  10bit-工作机器id，用来记录工作机器id,其中高位5bit是数据中心ID其取值范围0-31，低位5bit是工作节点ID其取值范围0-31，两个组合起来最多可以容纳1024个节点
> 4.  序列号占用12bit，每个节点每毫秒0开始不断累加，最多可以累加到4095，一共可以产生4096个ID

## 四、**ID生成策略对比** ##

**介绍了这些主键ID的生成策略，我们以后该用哪个呢?**

> **NONE:** 不设置id生成策略，MP不自动生成，约等于INPUT,所以这两种方式都需要用户手动设置，但是手动设置第一个问题是容易出现相同的ID造成主键冲突，为了保证主键不冲突就需要做很多判定，实现起来比较复杂
> 
> **AUTO:**数据库ID自增,这种策略适合在数据库服务器只有1台的情况下使用,不可作为分布式ID使用
> 
> **ASSIGN\_UUID:**可以在分布式的情况下使用，而且能够保证唯一，但是生成的主键是32位的字符串，长度过长占用空间而且还不能排序，查询性能也慢
> 
> **ASSIGN\_ID:**可以在分布式的情况下使用，生成的是Long类型的数字，可以排序性能也高，但是生成的策略和服务器时间有关，如果修改了系统时间就有可能导致出现重复主键
> 
> 综上所述，每一种主键策略都有自己的优缺点，根据自己项目业务的实际情况来选择使用才是最明智的选择

**简化配置**

前面我们已经完成了表关系映射、数据库主键策略的设置，接下来对于这两个内容的使用，我们再讲下他们的简化配置:

**模型类主键策略设置**

对于主键ID的策略已经介绍完，但是如果要在项目中的每一个模型类上都需要使用相同的生成策略，如:

![78c147d5fa6146b4aebb948181f96021.png][]

确实是稍微有点繁琐，我们能不能在某一处进行配置，就能让所有的模型类都可以使用该主键ID策略呢?

答案是肯定有，我们只需要在配置文件中添加如下内容:

mybatis-plus:
      global-config:
        db-config:
            id-type: assign_id

配置完成后，每个模型类的主键ID策略都将成为assign\_id.

![2f9764a64c694f179f76e4e7942ad37c.png][]

配置起来还是比较繁琐，简化方式为在配置文件中配置如下内容:

mybatis-plus:
      global-config:
        db-config:
            table-prefix: tbl_

## **五、多记录操作** ##

**删除指定多条数据**

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testDelete(){
            //删除指定多条数据
            List<Long> list = new ArrayList<>();
            list.add(1402551342481838081L);
            list.add(1402553134049501186L);
            list.add(1402553619611430913L);
            userDao.deleteBatchIds(list);
        }
    }

**以集合传值的方式删除**

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testGetByIds(){
            //查询指定多条数据
            List<Long> list = new ArrayList<>();
            list.add(1L);
            list.add(3L);
            list.add(4L);
            userDao.selectBatchIds(list);
        }
    }

**逻辑删除**

接下来要讲解是删除中比较重要的一个操作，逻辑删除，先来分析下问题:

![cdcb3df128f8478cb962db06958cc003.png][]

> 这是一个员工和其所签的合同表，关系是一个员工可以签多个合同，是一个一(员工)对多(合同)的表
> 
> 员工ID为1的张业绩，总共签了三个合同，如果此时他离职了，我们需要将员工表中的数据进行删除，会执行delete操作
> 
> 如果表在设计的时候有主外键关系，那么同时也得将合同表中的前三条数据也删除掉

![d28636e49c844b6abcff99bc7237bdc1.png][]

> 后期要统计所签合同的总金额，就会发现对不上，原因是已经将员工1签的合同信息删除掉了
> 
> 如果只删除员工不删除合同表数据，那么合同的员工编号对应的员工信息不存在，那么就会出现垃圾数据，就会出现无主合同，根本不知道有张业绩这个人的存在
> 
> 所以经过分析，我们不应该将表中的数据删除掉，而是需要进行保留，但是又得把离职的人和在职的人进行区分，这样就解决了上述问题，如:

![79a00a72af4749869879de90569e3f4b.png][]

> 区分的方式，就是在员工表中添加一列数据`deleted`，如果为0说明在职员工，如果离职则将其改完1，（0和1所代表的含义是可以自定义的）
> 
> 所以对于删除操作业务问题来说有:
> 
> 物理删除:业务数据从数据库中丢弃，执行的是delete操作
> 
> 逻辑删除:为数据设置是否可用状态字段，删除时设置状态字段为不可用状态，数据保留在数据库中，执行的是update操作

**MP中逻辑删除具体该如何实现?**

**修改数据库表添加`deleted`列**

字段名可以任意，内容也可以自定义，比如`0`代表正常，`1`代表删除，可以在添加列的同时设置其默认值为`0`正常。

![d2473f292ebd45d1ad9b51db954c4928.png][]

**实体类添加属性**

(1)添加与数据库表的列对应的一个属性名，名称可以任意，如果和数据表列名对不上，可以使用@TableField进行关系映射，如果一致，则会自动对应。

(2)标识新增的字段为逻辑删除字段，使用`@TableLogic`

@Data
    //@TableName("tbl_user") 可以不写是因为配置了全局配置
    public class User {
        @TableId(type = IdType.ASSIGN_UUID)
        private String id;
        private String name;
        @TableField(value="pwd",select=false)
        private String password;
        private Integer age;
        private String tel;
        @TableField(exist=false)
        private Integer online;
        @TableLogic(value="0",delval="1")
        //value为正常数据的值，delval为删除数据的值
        private Integer deleted;
    }

**运行删除方法**

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testDelete(){
           userDao.deleteById(1L);
        }
    }

![b862fef46a8e4194af3aaf4c100bcf7e.png][]

从测试结果来看，逻辑删除最后走的是update操作，会将指定的字段修改成删除状态对应的值。

**思考**

逻辑删除，对查询有没有影响呢?

执行查询操作

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testFind(){
           System.out.println(userDao.selectList(null));
        }
    }

运行测试，会发现打印出来的sql语句中会多一个查询条件。

可想而知，MP的逻辑删除会将所有的查询都添加一个未被删除的条件，也就是已经被删除的数据是不应该被查询出来的。

如果还是想把已经删除的数据都查询出来该如何实现呢?

@Mapper
    public interface UserDao extends BaseMapper<User> {
        //查询所有数据包含已经被删除的数据
        @Select("select * from tbl_user")
        public List<User> selectAll();
    }

如果每个表都要有逻辑删除，那么就需要在每个模型类的属性上添加`@TableLogic`注解，如何优化?

在配置文件中添加全局配置，如下:

mybatis-plus:
      global-config:
        db-config:
          # 逻辑删除字段名
          logic-delete-field: deleted
          # 逻辑删除字面值：未删除为0
          logic-not-delete-value: 0
          # 逻辑删除字面值：删除为1
          logic-delete-value: 1

介绍完逻辑删除，逻辑删除的本质为:

**逻辑删除的本质其实是修改操作。如果加了逻辑删除字段，查询数据时也会自动带上逻辑删除字段。**

执行的SQL语句为:

UPDATE tbl_user SET deleted=1 where id = ? AND deleted=0

**@TableLogic**

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>@TableLogic</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>类型</td> 
   <td>==属性注解==</td> 
  </tr> 
  <tr> 
   <td>位置</td> 
   <td>模型类中用于表示删除字段的属性定义上方</td> 
  </tr> 
  <tr> 
   <td>作用</td> 
   <td>标识该字段为进行逻辑删除的字段</td> 
  </tr> 
  <tr> 
   <td>相关属性</td> 
   <td>value：逻辑未删除值 delval:逻辑删除值</td> 
  </tr> 
 </tbody> 
</table>

## 六、乐观锁 ##

### 1、概念 ###

在讲解乐观锁之前，我们还是先来分析下问题:

> 业务并发现象带来的问题:**秒杀**
> 
> 假如有100个商品或者票在出售，为了能保证每个商品或者票只能被一个人购买，如何保证不会出现超买或者重复卖
> 
> 对于这一类问题，其实有很多的解决方案可以使用
> 
> 第一个最先想到的就是锁，锁在一台服务器中是可以解决的，但是如果在多台服务器下锁就没有办法控制，比如12306有两台服务器在进行卖票，在两台服务器上都添加锁的话，那也有可能会导致在同一时刻有两个线程在进行卖票，还是会出现并发问题
> 
> 我们接下来介绍的这种方式是针对于小型企业的解决方案，因为数据库本身的性能就是个瓶颈，如果对其并发量超过2000以上的就需要考虑其他的解决方案了。
> 
> 简单来说，乐观锁主要解决的问题是当要更新一条记录的时候，希望这条记录没有被别人更新。

### 2、实现思路 ###

乐观锁的实现方式:

>  *  数据库表中添加version列，比如默认值给1
>  *  第一个线程要修改数据之前，取出记录时，获取当前数据库中的version=1
>  *  第二个线程要修改数据之前，取出记录时，获取当前数据库中的version=1
>  *  第一个线程执行更新时，set version = newVersion where version = oldVersion
>     
>      *  newVersion = version+1 \[2\]
>      *  oldVersion = version \[1\]
>  *  第二个线程执行更新时，set version = newVersion where version = oldVersion
>     
>      *  newVersion = version+1 \[2\]
>      *  oldVersion = version \[1\]
>  *  假如这两个线程都来更新数据，第一个和第二个线程都可能先执行
>     
>      *  假如第一个线程先执行更新，会把version改为2，
>      *  第二个线程再更新的时候，set version = 2 where version = 1,此时数据库表的数据version已经为2，所以第二个线程会修改失败
>      *  假如第二个线程先执行更新，会把version改为2，
>      *  第一个线程再更新的时候，set version = 2 where version = 1,此时数据库表的数据version已经为2，所以第一个线程会修改失败
>      *  不管谁先执行都会确保只能有一个线程更新数据，这就是MP提供的乐观锁的实现原理分析。

**上面所说的步骤具体该如何实现呢?**

### 3、实现步骤 ###

分析完步骤后，具体的实现步骤如下:

**数据库表添加列**

列名可以任意，比如使用`version`,给列设置默认值为`1`

![66d1ba3c09a0419d81926cbe08ca2f77.png][]

**在模型类中添加对应的属性**

根据添加的字段列名，在模型类中添加对应的属性值

@Data
    //@TableName("tbl_user") 可以不写是因为配置了全局配置
    public class User {
        @TableId(type = IdType.ASSIGN_UUID)
        private String id;
        private String name;
        @TableField(value="pwd",select=false)
        private String password;
        private Integer age;
        private String tel;
        @TableField(exist=false)
        private Integer online;
        private Integer deleted;
        @Version
        private Integer version;
    }

**添加乐观锁的拦截器**

@Configuration
    public class MpConfig {
        @Bean
        public MybatisPlusInterceptor mpInterceptor() {
            //1.定义Mp拦截器
            MybatisPlusInterceptor mpInterceptor = new MybatisPlusInterceptor();
            //2.添加乐观锁拦截器
            mpInterceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
            return mpInterceptor;
        }
    }

**执行更新操作**

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testUpdate(){
           User user = new User();
            user.setId(3L);
            user.setName("Jock666");
            userDao.updateById(user);
        }
    }

![0214b6fbc14c41458ba8203b3107c22a.png][]

你会发现，这次修改并没有更新version字段，原因是没有携带version数据。

添加version数据

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testUpdate(){
            User user = new User();
            user.setId(3L);
            user.setName("Jock666");
            user.setVersion(1);
            userDao.updateById(user);
        }
    }

![68567d55d7304cd097350186d5ae909a.png][]

你会发现，我们传递的是1，MP会将1进行加1，然后，更新回到数据库表中。

所以要想实现乐观锁，首先第一步应该是拿到表中的version，然后拿version当条件在将version加1更新回到数据库表中，所以我们在查询的时候，需要对其进行查询

![b68245be6dcc468a8db22a87e149dacf.png][]

大概分析完乐观锁的实现步骤以后，我们来模拟一种加锁的情况，看看能不能实现多个人修改同一个数据的时候，只能有一个人修改成功。

@SpringBootTest
    class Mybatisplus03DqlApplicationTests {
    
        @Autowired
        private UserDao userDao;
        
        @Test
        void testUpdate(){
           //1.先通过要修改的数据id将当前数据查询出来
            User user = userDao.selectById(3L);     //version=3
            User user2 = userDao.selectById(3L);    //version=3
            user2.setName("Jock aaa");
            userDao.updateById(user2);              //version=>4
            user.setName("Jock bbb");
            userDao.updateById(user);               //verion=3?条件还成立吗？
        }
    }

乐观锁就已经实现完成了，如果对于上面的这些步骤记不住咋办呢?

参考官方文档来实现:

`https://mp.baomidou.com/guide/interceptor-optimistic-locker.html#optimisticlockerinnerinterceptor`

![d0c3dbc7f322467fb25de2515654f87e.png][]

> **不积跬步无以至千里，趁年轻，使劲拼，给未来的自己一个交代！向着明天更好的自己前进吧！**
> 
> ![d5358fcd619443fe98143f2fd5fef762.gif][]

[168c1abc67f4402ebfc99ff077a3e4da.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/5b0b4a08b586437195f2c0198438d8cb.gif
[Link 1]: https://blog.csdn.net/aasd23?spm=1000.2115.3001.5343
[Java_]: https://blog.csdn.net/aasd23/category_12005462.html?spm=1001.2014.3001.5482
[85e2fb30c7bb4d09a338cc3b1f893177.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/abab456a26344c7bbe02aec85857d148.png
[4d719f0362654fdab4d090b1099ad415.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/601709fa17cb4b7d8ad7155f8079b484.png
[206590b560624714bc2d43c6fb20841d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/394b0e521b7e40edb631c67711912863.png
[78c147d5fa6146b4aebb948181f96021.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/a26275cf089d44298087b546a700e096.png
[2f9764a64c694f179f76e4e7942ad37c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/d432229e406f41aba77f9b99022777e9.png
[cdcb3df128f8478cb962db06958cc003.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/715d3cd4ca9f42129c1f27ba5a6bb96b.png
[d28636e49c844b6abcff99bc7237bdc1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/0c777bb6c8c74025b108e19b8c0f4348.png
[79a00a72af4749869879de90569e3f4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/863c51a49f804b569d69f4271e740a44.png
[d2473f292ebd45d1ad9b51db954c4928.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/13f3255ad44e4960a54cc3cf453f87ce.png
[b862fef46a8e4194af3aaf4c100bcf7e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/c8e46009c00f4af09c99c881389110e5.png
[66d1ba3c09a0419d81926cbe08ca2f77.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/dd5392df2b354c9faedefc0cf259ca62.png
[0214b6fbc14c41458ba8203b3107c22a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/da12550da5e9474babfb33eca260cb91.png
[68567d55d7304cd097350186d5ae909a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/50a87ebbeda34dc8948e121b77ef7f51.png
[b68245be6dcc468a8db22a87e149dacf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/65c5f38218004c3da4f95b0a2bae9b02.png
[d0c3dbc7f322467fb25de2515654f87e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/c7746616b40d4d559322721f96c96f65.png
[d5358fcd619443fe98143f2fd5fef762.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/57392b771a354a3a9601baa6059f651f.gif