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("ppz@qq.com"); 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), ppz@qq.com(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=ppz@qq.com)
说明我们插入数据成功了,细心的人会发现我们并没有指定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("ppz@qq.com"); int count = userMapper.insert(userEntity); System.out.println(count); System.out.println(userEntity); }
控制台的部分打印为:
1
UserEntity(id=6, name=pipizhen, age=10, email=ppz@qq.com)
我们发现确实是我们熟悉的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都是没问题的,突然出现这个,也是很困惑
总结,出现这个问题的原因,还是因为自己技术不熟练啦~~
以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。