我要评论什么是主键生成策略
通过以下代码我们可以很直观的看出，当我们程序并没有set主键的时候，mybatis-plus是自动帮我们set了一个19位的id主键，这就体现了mybatis-plus的主键生成策略
附git地址：https://gitee.com/its-a-little-bad/mybatisplus—chapter-1.git
主键生成策略的配置方式
spring-boot
方式一：使用配置类
@bean
public ikeygenerator keygenerator() {
return new h2keygenerator();
}
方式二：通过 mybatispluspropertiescustomizer 自定义
@bean
public mybatispluspropertiescustomizer pluspropertiescustomizer() {
return plusproperties -> plusproperties.getglobalconfig().getdbconfig().setkeygenerator(new h2keygenerator());
}
spring
方式一: xml 配置
<bean id="globalconfig" class="com.baomidou.mybatisplus.core.config.globalconfig"> <property name="dbconfig" ref="dbconfig"/> </bean> <bean id="dbconfig" class="com.baomidou.mybatisplus.core.config.globalconfig.dbconfig"> <property name="keygenerator" ref="keygenerator"/> </bean> <bean id="keygenerator" class="com.baomidou.mybatisplus.extension.incrementer.h2keygenerator"/>
方式二：注解配置
@bean
public globalconfig globalconfig() {
globalconfig conf = new globalconfig();
conf.setdbconfig(new globalconfig.dbconfig().setkeygenerator(new h2keygenerator()));
return conf;
}
主键生成策略的实现方式
自动增长策略（auto）
/**
* 数据库id自增
*/
auto(0),
最常见的方式：利用数据库，全数据库唯一。
优点：
1）简单，代码方便，性能可以接受。
2）数字id天然排序，对分页或者需要排序的结果很有帮助。
缺点：
1）不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
2）在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
3）在性能达不到要求的情况下，比较难于扩展。（不适用于海量高并发）
4）如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
5）分表分库的时候会有麻烦。
6）并非一定连续，类似mysql，当生成新id的事务回滚，那么后续的事务也不会再用这个id了。这个在性能和连续性的折中。如果为了保证连续，必须要在事务结束后才能生成id，那性能就会出现问题。
7）在分布式数据库中，如果采用了自增主键的话，有可能会带来尾部热点。分布式数据库常常使用range的分区方式，在大量新增记录的时候，io会集中在一个分区上，造成热点数据。
优化方案：
1）针对主库单点，如果有多个master库，则每个master库设置的起始数字不一样，步长一样，可以是master的个数。比如：master1生成的是 1，4，7，10，master2生成的是2,5,8,11 master3生成的是
3,6,9,12。这样就可以有效生成集群中的唯一id，也可以大大降低id生成数据库操作的负载。
全局唯一id (uuid)
/**
* 全局唯一id (uuid)
*/
uuid(4),
常见的方式：可以利用数据库也可以利用程序生成，一般来说全球唯一。uuid是由32个的16进制数字组成，所以每个uuid的长度是128位（16^32 = 2^128）。uuid作为一种广泛使用标准，有多个实现版本，影响它的因素包括时间、网卡mac地址、自定义namesapce等等。
优点：
1）简单，代码方便。
2）生成id性能非常好，基本不会有性能问题。
3）全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。
缺点：
1）没有排序，无法保证趋势递增。
2）uuid往往是使用字符串存储，查询的效率比较低。
3）存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
4）传输数据量大
5）不可读。
深入uuid的变种（了解即可）
//为了解决uuid不可读，可以使用uuid to int64的方法
public static long guidtoint64()
{
byte[] bytes = guid.newguid().tobytearray();
return bitconverter.toint64(bytes, 0);
}
//为了解决uuid无序的问题，nhibernate在其主键生成方式中提供了comb算法（combined guid/timestamp）。保留guid的10个字节，用另6个字节表示guid生成的时间（datetime）
private guid generatecomb()
{
byte[] guidarray = guid.newguid().tobytearray();
datetime basedate = new datetime(1900, 1, 1);
datetime now = datetime.now;
timespan days = new timespan(now.ticks - basedate.ticks);
timespan msecs = now.timeofday;
byte[] daysarray = bitconverter.getbytes(days.days);
byte[] msecsarray = bitconverter.getbytes((long)
(msecs.totalmilliseconds / 3.333333));
array.reverse(daysarray);
array.reverse(msecsarray);
array.copy(daysarray, daysarray.length - 2, guidarray,
guidarray.length - 6, 2);
array.copy(msecsarray, msecsarray.length - 4, guidarray,
guidarray.length - 4, 4);
return new guid(guidarray);
}
redis生成id
使用场景：当使用数据库来生成id性能不够要求的时候，我们可以尝试使用redis来生成id。这主要依赖于redis是单线程的，所以也可以用生成全局唯一的id。可以用redis的原子操作incr和incrby来实现。
举例：可以使用redis集群来获取更高的吞吐量。假如一个集群中有5台redis。可以初始化每台redis的值分别是1,2,3,4,5，然后步长都是5。各个redis生成的id为：
a：1,6,11,16,21
b：2,7,12,17,22
c：3,8,13,18,23
d：4,9,14,19,24
e：5,10,15,20,25
优点：
1）不依赖于数据库，灵活方便，且性能优于数据库。
2）数字id天然排序，对分页或者需要排序的结果很有帮助。
缺点：
1）如果系统中没有redis，还需要引入新的组件，增加系统复杂度。
2）需要编码和配置的工作量比较大
mp自带策略（twitter的snowflake算法）
snowflake是twitter开源的分布式id生成算法，结果是一个long型的id。
核心思想：使用41bit作为毫秒数，10bit作为机器的id（5个bit是数据中心，5个bit的机器id），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生4096 个id），最后还有一个符号位，永远是0。具体实现的代码可以参看https://github.com/twitter/snowflake。
tps：雪花算法支持的tps可以达到419万左右（2^22*1000）。
主键生成策略的源码剖析(idtype类详解)
public enum idtype {
/**
* 数据库id自增
*/
auto(0),
/**
* 该类型为未设置主键类型,如须使用需要手动设置
*/
none(1),
/**
* 用户输入id
* 该类型可以通过自己注册自动填充插件进行填充,如须使用需要手动设置
*/
input(2),
/**
* 全局唯一id (uuid)
*/
uuid(4),
//以下两种为mp自带策略
/**
* 全局唯一id (idworker),生成19位值，数字类型使用这种策略，比如long
*/
id_worker(3),
/**
* 字符串全局唯一id，生成19位值，字符串类型使用这种策略，比如string
*/
id_worker_str(5);
}到此这篇关于mybatis-plus主键生成策略的实现方法的文章就介绍到这了,更多相关mybatis-plus主键生成策略内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论