MybatisPlus中的insert操作详解

目录

• MybatisPlus insert操作
• 1、开启日志
• 2、测试插入的代码
• 3、MybatisPlus使用的是雪花算法
• 4、MybatisPlus中的主键生成策略
• 5、测试不同的主键生成策略
• MybatisPlus坑insert方法
• 着手解决

MybatisPlus insert操作

在测试之前，我们思考一个问题，上个入门案例中，我们什么sql语句代码都没写，但也能查询出来数据。

是谁帮我们做了写基本代码的事情？肯定是MybatisPlus。

为了验证并继续向下学习，我们开启日志，打印在控制台上。

1、开启日志

只需在yml配置文件中，写上：

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

2、测试插入的代码

    @Test
    void testInsert() {
        UserEntity userEntity = new UserEntity();
        userEntity.setName("pipizhen");
        userEntity.setAge(10);
        userEntity.setEmail("[email protected]");
        int count = userMapper.insert(userEntity);

        System.out.println(count);
        System.out.println(userEntity);
    }

控制台输出：

Creating a new SqlSession
SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@2373ad99] was not registered for synchronization because synchronization is not active
2020-11-23 14:13:12.748  INFO 7392 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2020-11-23 14:13:13.028  INFO 7392 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
JDBC Connection [HikariProxyConnection@1977652583 wrapping com.mysql.cj.jdbc.ConnectionImpl@2a334bac] will not be managed by Spring
==>  Preparing: INSERT INTO tbl_user ( id, name, email, age ) VALUES ( ?, ?, ?, ? ) 
==> Parameters: 1330756266048045058(Long), pipizhen(String), [email protected](String), 10(Integer)
<==    Updates: 1
Closing non transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@2373ad99]
1
UserEntity(id=1330756266048045058, name=pipizhen, age=10, [email protected])

说明我们插入数据成功了，细心的人会发现我们并没有指定id，但插入成功后，我们发现对象存在id。

肯定是主键自动生成的，没错，但是怎么生成一个这么大的数字呢？为什么不是在原有的记录条数id在自增1呢？

这里数据库插入的id的默认值为：全局唯一id。

全局唯一id可自行百度：分布式系统唯一id生成。

3、MybatisPlus使用的是雪花算法

原理：Twitter的雪花算法SnowFlake，使用Java语言实现。

可以了解一下：

SnowFlake算法产生的ID是一个64位的整型，结构如下（每一部分用“-”符号分隔）：

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

• 1位标识部分，在java中由于long的最高位是符号位，正数是0，负数是1，一般生成的ID为正数，所以为0；
• 41位时间戳部分，这个是毫秒级的时间，一般实现上不会存储当前的时间戳，而是时间戳的差值（当前时间-固定的开始时间），这样可以使产生的ID从更小值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L606024365) = 69年；
• 10位节点部分，Twitter实现中使用前5位作为数据中心标识，后5位作为机器标识，可以部署1024个节点；
• 12位序列号部分，支持同一毫秒内同一个节点可以生成4096个ID；

SnowFlake算法生成的ID大致上是按照时间递增的，用在分布式系统中时，需要注意数据中心标识和机器标识必须唯一，这样就能保证每个节点生成的ID都是唯一的。或许我们不一定都需要像上面那样使用5位作为数据中心标识，5位作为机器标识，可以根据我们业务的需要，灵活分配节点部分，如：若不需要数据中心，完全可以使用全部10位作为机器标识；若数据中心不多，也可以只使用3位作为数据中心，7位作为机器标识。

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。

4、MybatisPlus中的主键生成策略

我们可以在@TableId注解中发现有个属性IdType，这是一个枚举类。

旧版本的枚举值有AUTO, NONE, INPUT, ID_WORKER, UUID, ID_WORKER_STR;

新版本又增加了两种，ASSIGN_ID，ASSIGN_UUID。

旧版本当我们不指定主键生成类型时，即值为null时，默认使用ID_WORKER类型。

新版本默认为NONE，注解里等于跟随全局，全局里约等于 INPUT。

（1）AUTO：数据库ID自增。

（2）NONE：无状态,该类型为未设置主键类型(注解里等于跟随全局,全局里约等于 INPUT)。

（3）INPUT：insert前自行set主键值，即我们插入前，需要手动设置id。

（4）ASSIGN_ID：分配ID(主键类型为Number(Long和Integer)或String)(since 3.3.0),使用接口IdentifierGenerator的方法nextId(默认实现类为DefaultIdentifierGenerator雪花算法)。

（5）ASSIGN_UUID：分配UUID,主键类型为String(since 3.3.0),使用接口IdentifierGenerator的方法nextUUID(默认default方法)

（6）ID_WORKER：分布式全局唯一ID 长整型类型(please use ASSIGN_ID)。

（7）UUID：32位UUID字符串(please use ASSIGN_UUID)。

（8）ID_WORKER_STR 分布式全局唯一ID 字符串类型(please use ASSIGN_ID)

注意：最后三个在最新版本中，ID_WORKER，UUID，ID_WORKER_STR已经被遗弃了，不建议使用。

5、测试不同的主键生成策略

（1）AUTO策略

我们修改实体类中的id注解为：@TableId(value = “id”, type = IdType.AUTO)

并修改数据库中表tbl_user的id确定为自增。不然启动会报错：Field ‘id’ doesn’t have a default value.

测试之前，我们还需把表中那个id好长的记录删掉，并重启MySQL软件，我的是Navicat。目的防止缓存的影响。

测试程序还是上面那几行代码：

@Test
    void testInsert() {
        UserEntity userEntity = new UserEntity();
        userEntity.setName("pipizhen");
        userEntity.setAge(10);
        userEntity.setEmail("[email protected]");
        int count = userMapper.insert(userEntity);
        System.out.println(count);
        System.out.println(userEntity);
    }

控制台的部分打印为：

1
UserEntity(id=6, name=pipizhen, age=10, [email protected])

我们发现确实是我们熟悉的id自增1。

（2）INPUT策略

需要我们手动设置id的值，这样设置时，当数据库表的id设置了自增，插入时可设置id，也可不设置id。

当数据库表id没有设置自增，那我们插入数据时就必须设置id，不然谁来帮我们设置id的值，大家都知道id存在主键约束。

（3）ASSIGN_ID策略

也是自动生成一个很长的Long型数字。

可以自己尝试测试一下，只需改变实体类中注解中的IdType属性值。

MybatisPlus坑insert方法

有天早上我的一个同事，突然跑来告诉我。我们某张表的自增ID变得很大。类似1173776258468638722 这种。这个当然是不能接受的啊。

着手解决

然后就开始找问题的原因，一开始我想的是数据库上的问题，我删掉不合理的数据，

alter table *** AUTO_INCREMENT=20

修改自增ID从20开始。手动插入数据，居然OK。

那就说明，可能是我们代码insert数据的时候存在的问题。我找到数据库访问层的insert语句处，发现使用的是mybatis-plus，网上查了一下关于这块的东西，发现insert方法在配置的时候，可以指定自增ID的方式。

源码中定义有以下几种

public enum IdType {
    AUTO(0, "数据库ID自增"),
    INPUT(1, "用户输入ID"),
    ID_WORKER(2, "全局唯一ID"),
    UUID(3, "全局唯一ID"),
    NONE(4, "该类型为未设置主键类型"),
    ID_WORKER_STR(5, "字符串全局唯一ID");

然后我就果断手动配置了一下，

    @TableId(type = IdType.AUTO)
    private Long userId;

重启测试，OK。

也是很奇怪为什么之前的那部分数据的自增ID都是没问题的，突然出现这个，也是很困惑

总结，出现这个问题的原因，还是因为自己技术不熟练啦~~

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。