当前位置:   article > 正文

MyBatisPlus4-DML编程控制(增删改)、id生成策略、逻辑删除、乐观锁和悲观锁_mybatis id生成策略

mybatis id生成策略

1. id生成策略控制(增)

在这里插入图片描述

名称: @TableId
类型: 属性注解
位置: 模型类中用于表示主键的属性定义上方
作用: 设置当前类中主键属性的生成策略

public class User {
	@TableId(type = IdType.AUTO)
	private Long id;
}
  • 1
  • 2
  • 3
  • 4

value: 设置数据库主键名称
type: 设置主键属性的生成策略,值参照IdType枚举值

type = IdType.AUTO 表示自增生成id

type = IdType.INPUT 需要自己写入id

type = IdType.ASSIGN_ID 生成式id(雪花算法生成),可兼容数值型与字符串型

在这里插入图片描述
雪花算法生成的ID是一个64位整数,其中包含了以下信息:

  • 1位标志位:固定为0,表示这是一个正整数;
  • 41位的时间戳:精度为毫秒,可以使用69年;
  • 10位的工作机器ID:用来标识数据中心和机器,最多可以使用1024台机器;
  • 12位的序列号:每台机器每毫秒可以生成最多4096个ID。

这样,即使在分布式系统中生成ID,也可以保证ID的全局唯一性和有序性,而且也可以根据ID的组成部分推断出ID的生成时间和所在机器的信息。
雪花算法实现简单,不需要任何分布式锁支持,在高并发场景下生成ID性能优异,被广泛应用于分布式系统中的数据标识和生成。

type = IdType.ASSIGN_UUID 以UUID生成算法作为id生成策略

为了避免在每个实体类中都写生成id策略,可以直接配置文件中全局设定

# mp日志
mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    # 让应用程序在启动时不打印Spring Banner,从而简化控制台输出信息,减少不必要的干扰
    # Spring Banner 是启动程序时打印在控制台上的 ASCII 艺术图
    banner: false
    db-config:
     	# id生成策略全局配置
 		id-type: assign_id
 		# 表名前缀全局配置,这样就不用再实体类中配置@TableName()属性了,直接实现表名与实体类名的自动映射
 		table-prefix: tbl_
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

2. 多记录操作(删)

2.1 根据id值批量删除

    @Test
    void testDelete(){
        //删除指定多条数据
        List<Long> list = new ArrayList<>();
        list.add(1402551342481838081L);
        list.add(1402553134049501186L);
        list.add(1402553619611430913L);
        userDao.deleteBatchIds(list);
        
        //也支持查询指定多条数据
//        List<Long> list = new ArrayList<>();
//        list.add(1L);
//        list.add(3L);
//        list.add(4L);
//        userDao.selectBatchIds(list);
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

2.2 逻辑删除

删除操作业务问题:数据从数据库中丢弃,存在一些逻辑问题,例如员工离职,就把员工删除会出现一些关联的表也删除记录,就出现了一些问题;

在这里插入图片描述

逻辑删除:删除时设置状态字段为不可用状态,而不是真的删除数据

在这里插入图片描述

首先实体类字段中添加一个标记状态字段(数据库表中同样要添加一个字段)

//逻辑删除字段,标记当前记录是否被删除
//value表示是默认值为0(与数据库中对应),delval表示逻辑删除值为1
@TableLogic(value = "0", delval = "1")
Integer deleted;
  • 1
  • 2
  • 3
  • 4

测试删除,并且删除操作之后进行查询操作

@Test
public void testDeleteById(){
	userDao.deleteById(1L);
	System.out.println(userDao.selectList(null));
}
  • 1
  • 2
  • 3
  • 4
  • 5

id为1的记录被逻辑删除之后不能被查询出来,如果之后有业务需求,需要将标记字段为0和1的记录都查询出来,需要手动写SQL而不采用MP;
逻辑删除实际执行的是一个update操作,遇到关联删除的话写SQL;

在这里插入图片描述

在实体类中的逻辑删除注解可以做全局配置

mybatis-plus:
  global-config:
    db-config:
      id-type: assign_id
      table-prefix: tbl_
      # 逻辑删除
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

3. 乐观锁(改)

这里乐观锁和悲观锁的一些基本概念

3.1 乐观锁

  1. 乐观锁是一种并发控制机制,它通过假定多个用户同时访问同一数据时并不会发生冲突,从而避免使用繁重的锁机制

  2. 机制就是当某用户对数据进行修改时,系统会先检查该数据的版本号是否与用户开始读取时一样,如果一样则允许修改,如果不一样则表示有其他用户修改过该数据,此时该用户的修改操作将被拒绝,需要重新读取数据并尝试修改。

  3. 乐观锁的好处是可以提高并发访问数据的效率,使用的成本比悲观锁低。但是也存在一定的风险,因为多个用户同时修改同一数据的机会仍然存在,在这种情况下,乐观锁可能会导致数据的不一致性,因此在高并发场景下需要谨慎地使用乐观锁。

3.2 悲观锁

  1. 悲观锁是一种并发控制机制,它假定多个用户同时访问同一数据时会发生冲突,因此在用户访问该数据时会将其锁定,其他用户尝试访问该数据时将会被阻塞,直到该用户释放锁

  2. 悲观锁的优点是能有效地保证数据的一致性,确保在多个用户同时访问同一数据时不会发生冲突。但其缺点也十分明显,因为悲观锁需要对数据进行加锁操作,所以在高并发的情况下,锁的争用会造成较高的系统开销,从而降低系统的性能。此外,如果某个用户持有锁的时间过长,就会导致其他用户的等待时间过长,瓶颈会从数据访问的繁忙程度变成等待锁的繁忙程度,从而限制了系统的吞吐量

  3. 因此,悲观锁一般仅适用于对数据访问冲突的可能性极为高的情况,如对于高并发的写操作而对于一些比较低并发度的场景,尽量使用乐观锁等其他更轻量级的并发控制方案

3.3 MP实现乐观锁(改操作)

实体类中添加对应字段,设定该字段为版本号标记字段

@Version
private Integer version;
  • 1
  • 2

MP中需要配置拦截器实现锁机制对应的动态SQL语句拼装(分页查询也需要配拦截器

@Configuration
public class MpConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor(){
        //1.定义MP拦截器
        MybatisPlusInterceptor mybatisPlusInterceptor = new MybatisPlusInterceptor();
        //2.添加分页拦截器
        mybatisPlusInterceptor.addInnerInterceptor(new PaginationInnerInterceptor());
        //3.添加乐观锁拦截器
        mybatisPlusInterceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
        
        return mybatisPlusInterceptor;
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

使用乐观锁机制在修改前必须先获取到对应数据的version方可正常进行

  1. 执行修改之前先要获取version值,所以先要进行查询操作
  2. 执行修改是使用version字段作为乐观锁检查依据

在这里插入图片描述

@Test
public void testUpdate(){
	//1.先通过要修改的数据id将当前数据查询出来
	User user = userDao.selectById(3L);     
	User user2 = userDao.selectById(3L);  
	  
	user2.setName("Jock aaa");
	userDao.updateById(user2);    
	          
	user.setName("Jock bbb");
	userDao.updateById(user);               
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

只有user2修改成功,验证了MP实现乐观锁机制

在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/AllinToyou/article/detail/435851
推荐阅读
相关标签
  

闽ICP备14008679号