1. id生成策略控制（增）
名称: @TableId
类型: 属性注解
位置: 模型类中用于表示主键的属性定义上方
作用: 设置当前类中主键属性的生成策略
public class User {
@TableId(type = IdType.AUTO)
private Long id;
}
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_
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);
}
2.2 逻辑删除
删除操作业务问题：数据从数据库中丢弃，存在一些逻辑问题，例如员工离职，就把员工删除会出现一些关联的表也删除记录，就出现了一些问题；
逻辑删除：删除时设置状态字段为不可用状态，而不是真的删除数据
首先实体类字段中添加一个标记状态字段（数据库表中同样要添加一个字段）
//逻辑删除字段，标记当前记录是否被删除
//value表示是默认值为0（与数据库中对应），delval表示逻辑删除值为1
@TableLogic(value = "0", delval = "1")
Integer deleted;
测试删除，并且删除操作之后进行查询操作
@Test
public void testDeleteById(){
userDao.deleteById(1L);
System.out.println(userDao.selectList(null));
}
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
3. 乐观锁（改）
这里乐观锁和悲观锁的一些基本概念
3.1 乐观锁
-
乐观锁是一种并发控制机制，它通过假定多个用户同时访问同一数据时并不会发生冲突，从而避免使用繁重的锁机制。
-
机制就是当某用户对数据进行修改时，系统会先检查该数据的版本号是否与用户开始读取时一样，如果一样则允许修改，如果不一样则表示有其他用户修改过该数据，此时该用户的修改操作将被拒绝，需要重新读取数据并尝试修改。
-
乐观锁的好处是可以提高并发访问数据的效率，使用的成本比悲观锁低。但是也存在一定的风险，因为多个用户同时修改同一数据的机会仍然存在，在这种情况下，乐观锁可能会导致数据的不一致性，因此在高并发场景下需要谨慎地使用乐观锁。
3.2 悲观锁
-
悲观锁是一种并发控制机制，它假定多个用户同时访问同一数据时会发生冲突，因此在用户访问该数据时会将其锁定，其他用户尝试访问该数据时将会被阻塞，直到该用户释放锁。
-
悲观锁的优点是能有效地保证数据的一致性，确保在多个用户同时访问同一数据时不会发生冲突。但其缺点也十分明显，因为悲观锁需要对数据进行加锁操作，所以在高并发的情况下，锁的争用会造成较高的系统开销，从而降低系统的性能。此外，如果某个用户持有锁的时间过长，就会导致其他用户的等待时间过长，瓶颈会从数据访问的繁忙程度变成等待锁的繁忙程度，从而限制了系统的吞吐量。
-
因此，悲观锁一般仅适用于对数据访问冲突的可能性极为高的情况，如对于高并发的写操作，而对于一些比较低并发度的场景，尽量使用乐观锁等其他更轻量级的并发控制方案。
3.3 MP实现乐观锁（改操作）
实体类中添加对应字段，设定该字段为版本号标记字段
@Version
private Integer version;
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;
}
}
使用乐观锁机制在修改前必须先获取到对应数据的version方可正常进行
- 执行修改之前先要获取version值，所以先要进行查询操作
- 执行修改是使用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);
}
只有user2修改成功，验证了MP实现乐观锁机制
