mybatisplus（一）主键生成策略和浅解锁机制

• mybasits-plus
• • mybtatis-plus id的生成
  • 乐观锁和悲观锁

1. 数据库自增
   数据库中一般自带的数据库id自主递增，

如果是用自动递增的话，分库后的id会互相没有关系，如果想要将他们联立起来，还得要得知上一个Id的末尾，再加上才可得到，就例如501=500+1;

还有就是mp(mybatis-plus)自带的一些id排列方式，采用的是snowflake(雪花)算法
AUTO：自动增长
Id_WORKER：mp自带策略，19位的值，用于数字类型
Id_WORKER_STR：mp自带策略，19位的值，用于字符串类型
INPUT:自己输入策略
NONE:没有策略
UUID:随机不重复的值

乐观锁和悲观锁用于并发的场景，一般乐观锁只用在高并发、多读少写的场景，而悲观锁则一般用于并发量不是很大，并且出现并发情况导致的异常用户和系统都很难以接受的情况下。

如果不考虑事务的隔离性，会产生脏读，不可重复度，幻读这些读问题
还有丢失更新的写问题。

何为丢失更新，举个例子，在2个人同时更改一个表中的某个内容时，最后提交数据的会把比他前一个人提交的数据给覆盖掉，这就是丢失更新

乐观锁能够解决这种问题

1. 乐观锁
   举个例子：乐观锁里面会有个verison，假设如果有两个人（a,b）同时想要对01这个id的age进行修改，假设a会比b快上那么一点点去提交事务，这时候加了了乐观锁的话，会先对应这个verison值，如果verison值一样，则将verison值加一，然后修改age，那么b提交时对照这个version的值，发现不一样，就无法完成事务提交，这就是乐观锁的机制

2. 悲观锁

何为悲观锁，用最通俗的话来说就是，举个例子：地铁进出的闸机，当一个人进入之后，下一个人才能进，相当于要排队一样，这会不同的乐观锁可以同时编辑，然后再对照version来做是否提交事务的判断，它从源头上直接锁死

##乐观锁的使用

首先需要在对应的数据库中插入一个version的字段

随后在自己的实体类中加多一个对应的属性version,记得@Version注解要加上

    @Version
    @TableField(fill = FieldFill.INSERT)//在插入时自动插入一个值（可自主设定）
    private Integer version;//版本号

然后在自己的mybatisplus的工具类中插入乐观锁的插件

public class mybatisPlusConfig {
    
    @Bean
    public OptimisticLockerInterceptor optimisticLockerInterceptor() {
        return new OptimisticLockerInterceptor();
    }

随后可以设定插入时给的一个值

@Override
public void insertFill(MetaObject metaObject) {
 
    this.setFieldValByName("version", 1, metaObject);
}

这样就把乐观锁给配置好了，每次更改的时候verison就会自动加一，解决了一个丢失更新的问题