Mybatis-Plus id生成策略控制-Toy模板网

这篇具有很好参考价值的文章主要介绍了Mybatis-Plus id生成策略控制。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

id生成策略控制

不同的表应用不同的id生成策略

名称 @TableId

AUTO策略

除了AUTO这个策略以外，还有如下几种生成策略:

分布式ID是什么?

INPUT策略

ASSIGN_ID策略

ASSIGN_UUID策略

雪花算法

ID生成策略对比

id生成策略控制
不同的表应用不同的id生成策略
- 日志：自增（1,2,3,4，……）
- 购物订单：特殊规则（FQ23948AK3843）
- 外卖单：关联地区日期等信息（10 04 20200314 34 91）
- 关系表：可省略id
- ……
名称 @TableId
类型属性注解
位置模型类中用于表示主键的属性定义上方
作用设置当前类中主键属性的生成策略
相关属性
- value(默认)：设置数据库表主键名称
- type:设置主键属性的生成策略，值参照IdType的枚举值
AUTO策略
使用数据库id自增策略控制id生成
步骤1:设置生成策略为AUTO
步骤2:运行新增方法
在使用该策略的时候一定要确保对应的数据库表设置了ID主键自增，否则无效
除了AUTO这个策略以外，还有如下几种生成策略:
- NONE:不设置id生成策略
- INPUT:用户手工输入id
- ASSIGN_ID:雪花算法生成id(可兼容数值型与字符串型)
- ASSIGN_UUID:以UUID生成算法作为id生成策略
其他的几个策略均已过时，都将被ASSIGN_ID和ASSIGN_UUID代替掉
分布式ID是什么?
- 当数据量足够大的时候，一台数据库服务器存储不下，这个时候就需要多台数据库服务器进行存储
- 比如订单表就有可能被存储在不同的服务器上
- 如果用数据库表的自增主键，因为在两台服务器上所以会出现冲突
- 这个时候就需要一个全局唯一ID,这个ID就是分布式ID
INPUT策略
用户手工输入id
步骤1:设置生成策略为INPUT
注意：这种ID生成策略，需要将表的自增策略删除掉
步骤2:添加数据手动设置ID
步骤3:运行新增方法
如果没有设置主键ID的值，则会报错，错误提示就是主键ID没有给值
如果设置了主键ID,则数据添加成功
ASSIGN_ID策略
雪花算法生成id
步骤1:设置生成策略为ASSIGN_ID
步骤2:添加数据不设置ID
注意:这种生成策略，不需要手动设置ID，如果手动设置ID，则会使用自己设置的值
步骤3:运行新增方法
ASSIGN_UUID策略
以UUID生成算法作为id生成策略
步骤1:设置生成策略为ASSIGN_UUID
使用uuid需要注意的是，主键的类型不能是Long，而应该改成String类型
步骤2:修改表的主键类型
主键类型设置为varchar，长度要大于32，因为UUID生成的主键为32位，如果长度小的话就会导致插入失败
步骤3:添加数据不设置ID
步骤4:运行新增方法
雪花算法
雪花算法(SnowFlake),是Twitter官方给出的算法实现是用Scala写的
其生成的结果是一个64bit大小整数
文章来源地址https://www.toymoban.com/news/detail-836313.html
(1)1bit,不用,因为二进制中最高位是符号位，1表示负数，0表示正数；生成的id一般都是用整数，所以最高位固定为0
(2)41bit-时间戳，用来记录时间戳，毫秒级
(3)10bit-工作机器id，用来记录工作机器id,其中高位5bit是数据中心ID其取值范围0-31，低位5bit是工作节点ID其取值范围0-31，两个组合起来最多可以容纳1024个节点
(4)序列号占用12bit，每个节点每毫秒0开始不断累加，最多可以累加到4095，一共可以产生4096个ID
ID生成策略对比
NONE:不设置id生成策略，MP不自动生成，约等于INPUT，所以这两种方式都需要用户手动设置，但是手动设置第一个问题是容易出现相同的ID造成主键冲突，为了保证主键不冲突就需要做很多判定，实现起来比较复杂
AUTO:数据库ID自增，这种策略适合在数据库服务器只有1台的情况下使用，不可作为分布式ID使用
ASSIGN_UUID:可以在分布式的情况下使用，而且能够保证唯一，但是生成的主键是32位的字符串，长度过长占用空间而且还不能排序，查询性能也慢
ASSIGN_ID:可以在分布式的情况下使用，生成的是Long类型的数字，可以排序性能也高，但是生成的策略和服务器时间有关，如果修改了系统时间就有可能导致出现重复主键