Mybatis-Plus 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大小整数

(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类型的数字，可以排序性能也高，但是生成的策略和服务器时间有关，如果修改了系统时间就有可能导致出现重复主键

总结

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

最新评论