一、为什么需要选择不同的id生成策略
不同的表的id:
日志:自增(1,2,3,4,……)
购物订单:特殊规则(FQ23948AK3843)
外卖单:关联地区日期等信息(10 04 20200314 34 91)
关系表:可省略id
……
不同的业务采用的ID生成方式应该是不一样的,那么在MyBatisPlus(以下简称MP)中都提供了哪些主键生成策略,以及我们该如何进行选择?
二、如何使用MP的id生成策略
环境搭建
pom.xml中添加对应的依赖
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.5.0</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.itheima</groupId>
<artifactId>mybatisplus_03_dml</artifactId>
<version>0.0.1-SNAPSHOT</version>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.4.1</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.1.16</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
创建实体类
这里需要使用到一个注解 @TableId( type = id生成策略 ) ,将改注解加到实体类的id属性上,如下:
@Data
@TableName("tbl_user")
public class User {
@TableId(type = IdType.AUTO)
private Long id;
...
}
其中的id生成策略的取值来自枚举类 IdType 如下:
![](https://i-blog.csdnimg.cn/blog_migrate/d531ebd138f280bc9b1902e57ea45f0b.png)
从源码中可以看到,公有如下几种生成策略:
AUTO:id自增
NONE: 不设置id生成策略
INPUT:用户手工输入id
ASSIGN_ID:雪花算法生成id
ASSIGN_UUID:以UUID生成算法作为id生成策略
其他的几个策略均已过时,都将被ASSIGN_ID和ASSIGN_UUID代替掉。
AUTO
使用AUTO策略的时候一定要确保对应的数据库表设置了ID主键自增,否则无效
另外,AUTO策略不能在分布式系统中使用,因为每台数据库服务器如果都基于本地的最新ID进行自增,那就会出现ID冲突
NONE
不设置id生成策略,MP不自动生成,约等于INPUT
INPUT
这种ID生成策略,需要将表的自增策略删除掉,然后手动设置ID值
void userSave(){
User user = new User();
//设置主键ID的值
user.setId(123456L);
//为其他属性赋值...
userDao.insert(user);
}
ASSIGN_ID
采用该策略时,如果用户自己设置ID,MP会使用用户设置的ID,如果用户不自己设置ID值,那么MP会根据雪花算法自动生成ID,该策略可在分布式系统中使用
雪花算法:
雪花算法生成的是一个64bit大小的整数(对应Long)
时间戳:用来记录时间戳,毫秒级
工作机器id:用来记录工作机器id
序列号:占用12bit,每个节点每毫秒0开始不断累加,最多可以累加到4095,一共可以产生4096个ID
从上面可以看出,ASSIGN_ID 生成的策略和服务器时间有关,如果修改了系统时间就有可能导致出现重复主键 ,这点需要注意
ASSIGN_UUID
ASSIGN_UUID是自动生成一个不重复的、长度为32位的字符串,也能在分布式系统中使用
因此使用ASSIGN_UUID时需要注意:
实体类的主键类型不能是String,而应该改成Long类型
表中的主键类型设置为varchar,长度要大于32,如果长度小的话就会导致插入失败
ASSIGN_UUID的缺点比较明显:生成的主键是32位的字符串,长度过长占用空间而且还不能排序,查询性能也慢