MyBatis-Plus默认提供了以下几种ID生成策略: AUTO:配合数据库设置自增主键,可以实现主键的自动增长。此策略下,ID的类型通常为number。 INPUT:由用户输入ID值。在插入数据时,需要手动指定ID值。 NONE:无状态ID生成器,该策略不生成ID,由数据库自行处理(例如,使用自增主键)。这实际上与INPUT类似,只是没有明确要求用...
接下来,验证一番后,发现,Mybatis-Plus在做insert操作时,确实自动生成了一条长19的数字当做该条数据的id插入到MySql,导致虽然MySql表设置了自增,但被该1468844351843872769影响了,导致下一条数据自动递增值变成了1468844351843872770,这种过长的id值,在做索引维护时,很影响效率,故而,这个问题必须得解决。 image.png 到...
Mybatis-Plus主要有以下几种主键生成策略—— @Getterpublic enum IdType {/*** 数据库ID自增*/AUTO(0),/*** 该类型为未设置主键类型*/NONE(1),/*** 用户输入ID* 该类型可以通过自己注册自动填充插件进行填充*/INPUT(2),/* 以下3种类型、只有当插入对象ID 为空,才自动填充。 *//*** 全局唯一ID ...
百度网上的说法,当Mybatis-Plus实体类没有显示设置主键策略时,将默认使用雪花算法生成,也就是IdType.ID_WORKER或者IdType.ID_WORKER_STR,具体是long类型的19位还是字符串的19位,应该是根据字段定义类型来判断。 snowflake算法是Twitter开源的分布式ID生成算法,结果是一个long类型的ID 。其核心思想:使用41bit作为毫秒...
百度网上的说法,当Mybatis-Plus实体类没有显示设置主键策略时,将默认使用雪花算法生成,也就是IdType.ID_WORKER或者IdType.ID_WORKER_STR,具体是long类型的19位还是字符串的19位,应该是根据字段定义类型来判断。 snowflake算法是Twitter开源的分布式ID生成算法,结果是一个long类型的ID 。其核心思想:使用41bit作为毫秒...
这就很奇怪了,目前该表数据量很少,且主键是设置AUTO_INCREMENT,正常而言,应该自增id仍在1000范围内,但目前已经变成一串长数字。 底层ORM框架用的是Mybatis-Plus,我寻思了一下,这看起来像是在插入数据库旧自动生成的id,导致并非默认使用MySql的自增AUTO_INCREMENT的id。
百度网上的说法,当Mybatis-Plus实体类没有显示设置主键策略时,将默认使用雪花算法生成,也就是IdType.ID_WORKER或者IdType.ID_WORKER_STR,具体是long类型的19位还是字符串的19位,应该是根据字段定义类型来判断。 snowflake算法是Twitter开源的分布式ID生成算法,结果是一个long类型的ID 。其核心思想:使用41bit作为毫秒...