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