MyBatisPlus4-DML编程控制（增删改）、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实现乐观锁机制