Interpretation of mybatisPlus primary key strategy

Table of contents

Introduction to primary key generation strategy

The role of the primary key is to uniquely identify, and we can use this unique identification to locate this piece of data. Of course, for the primary key in the table data, we can design the generation rules ourselves to generate the primary key. But in more scenarios, if there are no special requirements, it is troublesome for us to manually generate each time. We can use the framework to provide a good primary key generation strategy to generate the primary key. This is more convenient and quick

An annotation is provided in MybatisPlus, which is @TableId, which provides various primary key generation strategies. We can use this annotation to specify the primary key generation strategy for new data. Then when new data is added in the future, the data will generate the corresponding primary key according to the primary key generation strategy we specified.

@TableName("sys_user")
public class User {
    @TableId
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

Attributes	type	must specify	Defaults	describe
value	String	no	""	primary key field name
type	Enum	no	IdType.NONE	Specify the primary key type

The type type is as follows

value	describe
AUTO	Database ID auto-increment
NONE	Stateless, this type is the type that does not have a primary key set (in the annotation, it is equal to follow the global, and the global Rio is equal to INPUT)
INPUT	Set the primary key value before insert
ASSIGN_ID	Assign ID (primary key type is Number (Long and Integer) or String) (since 3.3.0), use interface `IdentifierGenerator`method `nextId`(default implementation class is `DefaultIdentifierGenerator`snowflake algorithm)
ASSIGN_UUID	Assign UUID, primary key type is String (since 3.3.0), use interface `IdentifierGenerator`method `nextUUID`(default default method)
~~ID_WORKER~~	Distributed globally unique ID long integer type (please use `ASSIGN_ID`)
~~UUID~~	32-bit UUID string (please use `ASSIGN_UUID`)
~~ID_WORKER_STR~~	Distributed globally unique ID string type (please use `ASSIGN_ID`)

AUTO strategy

This strategy follows the primary key increment strategy of the database table, provided that the primary key of the database table is set to auto-increment

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableId(type = IdType.AUTO)
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

@Test
void primaryKey(){
    User user = new User();
    user.setName("Mary");
    user.setAge(35);
    user.setEmail("[email protected]");
    userMapper.insert(user);
}

INPUT strategy

This strategy indicates that we must manually insert the id, otherwise the data cannot be added

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableId(type = IdType.INPUT)
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

If we omit the id here, we will find that the data cannot be inserted

@Test
void primaryKey(){
    User user = new User();
    user.setName("Jerry");
    user.setAge(38);
    user.setEmail("[email protected]");
    userMapper.insert(user);
}

But we specified the id ourselves and found that it can be added successfully

ASSIGN_ID strategy

Let's think about it, what's wrong with the automatic increment method like before?

If we have a large amount of data in a table in the future, we need to divide the table.

There are two common table splitting strategies

【1】Horizontal split

Horizontal splitting is to split a large table according to the amount of data

【2】Vertical split

Vertical splitting is to split a large table by field

In fact, we have three requirements for the split data, such as horizontal split:

[1] The primary key of the previous table is in order, and it is still in order after splitting

[2] Although the table has been split, each piece of data needs to ensure the uniqueness of the primary key

[3] It is best not to directly expose the amount of data in the primary key, so that the key information is easy to be known by the outside world

Then there needs to be an algorithm that can meet these three requirements. This algorithm is the snowflake algorithm.

The snowflake algorithm is composed of a 64-bit binary, which is ultimately a value of type Long. Mainly divided into four parts storage

[1] 1-bit sign bit, fixed value is 0

[2] 41-bit timestamp

[3] 10-digit machine code, including 5-digit machine id and 5-digit service id

【4】12-digit serial number

Use the snowflake algorithm to achieve ordered, unique numbers that do not directly expose the sort.

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableId(type = IdType.ASSIGN_ID)
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

NONE strategy

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableId(type = IdType.NONE)
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

The NONE strategy means that the primary key generation strategy is not specified. When we do not specify the primary key generation strategy or the primary key strategy is NONE, it follows the global strategy. The id-type in the global configuration is used to configure the primary key generation strategy. We can take a look Default value for id-type

By viewing the source code, it is found that the default value of id-type is the snowflake algorithm

ASSIGN_UUID policy

UUID ( Universally Unique Identifier ) is a globally unique identifier, defined as a string primary key, composed of 32 digits, encoded in hexadecimal , and defines system information that is completely unique in time and space.

Encoding rules for UUID:

[1] 1~8 digits adopt the system time, and the system time is accurate to the millisecond level to ensure the uniqueness of the time;

[2] 9~16 digits use the underlying IP address, which is unique in the server cluster;

[3] The 17~24 bits adopt the HashCode value of the current object, which is unique on an internal object;

[4] The 25~32 digits use a random number to call the method, which is unique at the millisecond level within an object.

Uniqueness can be guaranteed through the above four strategies. Where random numbers are needed in the system, the UUID algorithm can be considered.

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableId(type = IdType.ASSIGN_UUID)
    private String id;
    private String name;
    private Integer age;
    private String email;
}