MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（500W单表）

最新推荐文章于 2024-11-05 00:04:40 发布
最新推荐文章于 2024-11-05 00:04:40 发布
阅读量1w 收藏 3
点赞数 1
CC 4.0 BY-SA版权
分类专栏： mysql basic
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/csdnhsh/article/details/95757913

 

测试缘由

 

一个开发同事做了一个框架，里面主键是uuid，我跟他建议说mysql不要用uuid用自增主键，自增主键效率高，他说不一定高，我说innodb的索引特性导致了自增id做主键是效率最好的，为了说服他，所以准备做一个详细的测试。

 

作为互联网公司，一定有用户表，而且用户表UC_USER基本会有百万记录，所以在这个表基础上准测试数据来进行测试。

 

  大概环境是：Centos6.5、MySQL5.6.12

 

 

1、准备表以及数据

UC_USER，自增ID为主键：

CREATE TABLE `UC_USER` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用户名',
  `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密码',
  `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
  `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
  `USER_ICON` varchar(500) DEFAULT NULL COMMENT '头像图片',
  `SEX` char(1) DEFAULT NULL COMMENT '性别, 1:男，2:女，3：保密',
  `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵称',
  `STAT` varchar(10) DEFAULT NULL COMMENT '用户状态，01:正常，02:冻结',
  `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
  `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
  `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
  `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
  `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
  `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
  `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
  `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
  `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
  `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
  `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
  `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
  `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
  `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
  `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
  `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
  `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
  `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `USER_NAME` (`USER_NAME`),
  KEY `MOBILE` (`MOBILE`),
  KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
  KEY `IDX_EMAIL` (`EMAIL`,`ID`),
  KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
  KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB AUTO_INCREMENT=7122681 DEFAULT CHARSET=utf8 COMMENT='用户表'

 

 

 

UC_USER_PK_VARCHAR表，字符串ID为主键，采用uuid

CREATE TABLE `UC_USER_PK_VARCHAR_1` (
  `ID` varchar(36) CHARACTER SET utf8mb4 NOT NULL DEFAULT '0' COMMENT '主键',
  `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用户名',
  `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密码',
  `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
  `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
  `USER_ICON` varchar(500) DEFAULT NULL COMMENT '头像图片',
  `SEX` char(1) DEFAULT NULL COMMENT '性别, 1:男，2:女，3：保密',
  `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵称',
  `STAT` varchar(10) DEFAULT NULL COMMENT '用户状态，01:正常，02:冻结',
  `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
  `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
  `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
  `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
  `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
  `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
  `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
  `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
  `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
  `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
  `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
  `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
  `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
  `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
  `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
  `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
  `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
  `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `USER_NAME` (`USER_NAME`),
  KEY `MOBILE` (`MOBILE`),
  KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
  KEY `IDX_EMAIL` (`EMAIL`,`ID`),
  KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
  KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';

 

 

 

 

2、500W数据测试

2.1 录入500W数据，自增ID节省一半磁盘空间

确定两个表数据量

# 自增id为主键的表

mysql> select count(1) from UC_USER;

+----------+

| count(1) |

+----------+

|  5720112 |

+----------+

1 row in set (0.00 sec)

 

mysql>

 

# uuid为主键的表

mysql> select count(1) from UC_USER_PK_VARCHAR_1;                     

+----------+

| count(1) |

+----------+

|  5720112 |

+----------+

1 row in set (1.91 sec)

 

占据的空间容量来看，自增ID比UUID小一半左右。

主键类型

数据文件大小

占据容量

自增ID

-rw-rw---- 1 mysql mysql 2.5G Aug 11 18:29 UC_USER.ibd

2.5 G

UUID

-rw-rw---- 1 mysql mysql 5.4G Aug 15 15:11 UC_USER_PK_VARCHAR_1.ibd

5.4 G

 

 

 

2.2 单个数据走索引查询，自增id和uuid相差不大

主键类型

SQL语句

执行时间 (秒)

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` ='14782121512';

0.118

 

 

 

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';

0.117

 

 

 

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` IN( '14782121512','13761460105');

0.049

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` IN('14782121512','13761460105');

0.040

 

 

 

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:36' ;

0.139

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:43' ;

0.126

 

 

 

2.3 范围like查询，自增ID性能优于UUID

主键类型

SQL语句

执行时间 (秒)

 

（1）模糊范围查询1000条数据，自增ID性能要好于UUID

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;

1.784

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;

3.196

 

（2）日期范围查询20条数据，自增ID稍微弱于UUID

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;

0.601

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;

0.543

 

（3）范围查询200条数据，自增ID性能要好于UUID

自增ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;

2.314

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;

3.229

 

范围查询总数量，自增ID要好于UUID

自增ID

SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36'  ;

0.514

UUID

SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36'  ;

1.092

 

 

 

PS：在有缓存的情况下，两者执行效率没有相差很小。

 

 

 

2.4 写入测试，自增ID是UUID的4倍

主键类型

SQL语句

执行时间 (秒)

 

 

 

 

 

自增ID

UPDATE test.`UC_USER` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > '2016-05-03 10:26:36' AND t.`CREATE_DATE` <'2016-05-04 00:00:00'  ;

1.419  

UUID

UPDATE test.`UC_USER_PK_VARCHAR_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > '2016-05-03 10:26:36' AND t.`CREATE_DATE` <'2016-05-04 00:00:00'  ;

5.639

 

 

 

自增ID

INSERT INTO test.`UC_USER`(   ID,   `USER_NAME`,   `USER_PWD`,   `BIRTHDAY`,   `NAME`,   `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,   `USER_MALL`,   `LAST_LOGIN_DATE`,   `LAST_LOGIN_IP`,   `SRC_OPEN_USER_ID`,   `EMAIL`,   `MOBILE`,   `IS_DEL`,   `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,   `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` ) SELECT       NULL,    CONCAT('110',`USER_NAME`,8),   `USER_PWD`,   `BIRTHDAY`,   `NAME`,   `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,   `USER_MALL`,   `LAST_LOGIN_DATE`,   `LAST_LOGIN_IP`,   `SRC_OPEN_USER_ID`,   `EMAIL`, CONCAT('110',TRIM(`MOBILE`)),   `IS_DEL`,   `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,   `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100;

0.105

UUID

INSERT INTO test.`UC_USER_PK_VARCHAR_1`(    ID,   `USER_NAME`,   `USER_PWD`,   `BIRTHDAY`,   `NAME`,   `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,   `USER_MALL`,   `LAST_LOGIN_DATE`,   `LAST_LOGIN_IP`,   `SRC_OPEN_USER_ID`,   `EMAIL`,   `MOBILE`,   `IS_DEL`,   `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,   `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` ) SELECT         UUID(),   CONCAT('110',`USER_NAME`,8),   `USER_PWD`,   `BIRTHDAY`,   `NAME`,   `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,   `USER_MALL`,   `LAST_LOGIN_DATE`,   `LAST_LOGIN_IP`,   `SRC_OPEN_USER_ID`,   `EMAIL`, CONCAT('110',TRIM(`MOBILE`)),   `IS_DEL`,   `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,   `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100;

0.424

 

 

 

 

3、总结

在500W记录表的测试下：

（1）      普通单条或者20条左右的记录检索，uuid为主键的相差不大几乎效率相同；

（2）      但是范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；

（3）      在范围查询做统计汇总的时候，自增id的效率要大于uuid；

（4）      在存储上面，自增id所占的存储空间是uuid的1/2；

UUID 作为 Mysql 的主键优劣分析
java专栏
04-08 668
UUID 作为 MySQL 的主键有其独特的优势，但也存在一些明显的劣势。考虑到UUID的劣势，有些系统采用折衷方案来优化性能。索引效率：由于UUID的随机性，它们的数据分布会非常稀疏，这可能导致数据库在查询时需要更多的磁盘I/O操作，降低了索引的效率。UUID（Universally Unique Identifier，通用唯一识别码）作为 MySQL 数据库的主键，有其独特的优势和劣势。易于迁移和合并：由于UUID的唯一性，数据可以在不同的数据库或系统之间轻松迁移和合并，无需担心主键冲突。
数据库主键到底是用自增长好还是UUID好
关注我！带你一路 "狂飙" 到底！
08-09 3829
各位同学好，今天给大家讲一下MySQL数据库在设计主键时，应该使用哪种数据类型。我们知道，咱们在设计数据库时，主键是必须设置的。一般情况下，咱们都会选择使用主键自增或者UUID这两种主键策略。那么这两个哪种更好呢？我们应该使用哪一种呢，今天就请大家跟老徐来一起来学习一下吧。
mysql 使用uuid主键_MySQL UUID和主键（二十二）
weixin_39769183的博客
11-22 855
本教程将向您介绍MySQL UUID，并演示如何将其用作表的主键(PK)，并讨论将其用作主键的优缺点。MySQL UUID简介UUID代表通用唯一标识符。UUID是基于”RFC 4122“通用唯一标识符(UUID)URN命名空间”)定义的。UUID被设计为在空间和时间全球独一无二的数字。 预期两个UUID值是不同的，即使它们在两个独立的服务器上生成。在MySQL中，UUID值是一个128位的数字，...
mysql uuid 主键_将大型（UUID）作为MySQL表主键的最佳方式
weixin_32561885的博客
01-18 193
I have a UUID string that I want to use as my MySQL tables primary key, the UUID is a 32 character hexadecimal string (after '-' characters are stripped). Due to the fact that it is better to use a n...
数据库使用自增ID好还是UUID好？为什么？
西瓜的博客
05-15 1202
数据库使用自增ID好还是UUID好？为什么？
主键使用自增ID还是UUID?
IUUUUUUU的博客
04-02 268
主键使用自增ID还是UUID
MySQL使用自增ID主键和UUID作为主键的优劣
qq_28807077的博客
12-16 395
原文链接：https://blog.csdn.net/qq_30108237/article/details/106856051
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
hfdgjjg的博客
01-27 682
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
mysql-主键设计
饮啖茶食个包
09-01 1230
文章目录mysql-主键设计1 主键定义2 主键设计原则总原则：根据数据库表的具体使用范围来决定采用不同的表主键定义。数据库设计的三大范式反范式主键的设计原则2.1 确保主键的无意义性2.2 采用整型主键2.3 减少主键的变动2.4 避免重复使用主键2.5 主键字段定义区分3 主键方案3.1 自增ID（1）性能消耗（2）资源消耗优点：缺点：3.2 UUID优点：缺点：3.3 ID物理主键+UUID...
mysql的联合主键与复合主键区别
拿着核武器的程序员的博客
10-30 4620
复合主键就是指你表的主键含有一个以上的字段组成 。 例如； create table test ( name varchar(19), id number, value varchar(10), primary key (id,name) ) 上面的id和name字段组合起来就是你test表的复合主键 （若其一为单索引字段时，左边的id才会有索引） 它的出现是因为你的name字段可能会出现重名，所...
MySql 主键一般用自增ID还是UUID
书香水墨
12-15 4971
14、主键一般用自增ID还是UUID？ （1）自增ID： 使用自增ID的好处： 字段长度较 UUID 会小很多。 数据库自动编号，按顺序存放，利于检索 无需担心主键重复问题 使用自增ID的缺点： 因为是自增，在某些业务场景下，容易被其他人查到业务量。 发生数据迁移时，或者表合并时会非常麻烦 在高并发的场景下，竞争自增锁会降低数据库的吞吐能力 （2）UUID：通用唯一标识码，UUID是基于当前时间、计数器和硬件标识等数据计算生成的。 使用UUID的优点： 唯一标识，不用考虑重复问题，在数据拆分
mysql uhex_MySQL表中存储UUID值作为主键,使用UNHEX()提升性能
weixin_35545135的博客
01-19 534
假设我们有一个用户表，每个用户都有一个UUID。MySQL有一个UUID()函数，它使MySQL生成一个UUID值，并以VARCHAR(36)类型的可读形式返回。让我们试试MySQL 5.7.8：mysql> select uuid();+--------------------------------------+| uuid() ...
mysql 自增id和UUID做主键性能分析，及最优方案
XDSXHDYY的博客
01-07 1万+
mysql 自增id和UUID做主键性能分析，及最优方案 1.为什么要使用uuid做主键 (1).其实在innodb存储引擎下，自增长的id做主键性能已经达到了最佳。不论是存储和读取速度都是最快的，而且占的存储空间也是最小。 (2).但是在我们实际到项目中会碰到问题，历史数据表的主键id会与数据表的id重复，两张自增id做主键的表合并时，id一定会有冲突，但如果各自的id还关联了其他表，
详解：MySQL自增ID与UUID的优缺点及选择建议，MySQL有序uuid与自定义函数实现
是谢添啊
11-21 1万+
自增ID的优缺点，不适合以自增ID主键作为主键的情况，UUID介绍说明，uuid是什么，uuid的组成，UUID作为主键优缺点，mysql8.0的uuid_to_bin()函数分析及实现，mysql有序UUID实战，自定义uuid，自增id主键与自定义主键的选择建议，JDBCUtilsByDruid工具类，mysql数据类型binary，mysql函数hex()，mysql函数unhex()，bin_to_binary(uuid(),true)详细说明与实战/示例演示，什么是uuid
MySQL主键：自增ID与UUID的选择
My_wife_QBL的博客
06-27 713
在设计数据库表时，选择合适的主键类型是一个重要的决策。MySQL中，主键的选择通常在自增ID和UUID之间进行权衡。本文将探讨这两种主键类型的优缺点，以及在不同场景下的适用性。
uuid和自增id做主键哪个好，为什么？
weixin_56353201的博客
11-05 594
大的索引会占用更多的磁盘空间，导致缓存命中率下降，进而增加了磁盘I/O的需求。它可以使用不同的算法生成，比如基于时间戳的 UUID（version 1）和随机数生成的 UUID（version 4）等。● 不适合范围查询：因为不是自增的，所以在做范围查询的时候是不支持的。（后插入的UUID在排序时可能比前面的要小，在做范围查询的时候可能会出现数据重复或者漏数据的情况）● 不方便展示：主键ID有的时候会需要在系统间、或者前台页面展示，如果是UUID的话，就因为比较长、并且没有任何业务含义，所以不方便展示。
MybatisPlus 主键策略（type=IdType.ASSIGN_ID等详解）
热门推荐
DN金猿的博客
12-28 4万+
地址：https://www.hangge.com/blog/cache/detail_2904.html 三，主键策略 我们可以通过@TableId注解的类型属性来设置主键id的增长策略，一共有几个多个主键策略，可根据情况自由配置。 1，ASSIGN_ID（雪花算法） 如果不设置类型值，默认则使用IdType.ASSIGN_ID策略（自3.3.0起）。该策略会使用雪花算法自动生成主键ID，主键类型为长或字符串（分别对应的MySQL的表字段为BIGINT和VARCHAR） 提示：该策...
mybatis plus主键标注
最新发布
03-24
### MyBatis Plus 中主键生成策略及其标注方法 在 MyBatis Plus 中，可以通过 `@TableId` 注解为主键字段指定不同的生成策略。常见的主键生成方式包括数据库自增、UUID、雪花算法等。对于某些特定场景，可以使用 `@KeySequence` 注解配合序列（Sequence）实现主键生成。 #### 数据库主键自增 当数据库本身支持主键自增时，可以在实体类中通过如下方式进行配置： ```java @TableId(type = IdType.AUTO) private Long id; ``` 这种方式适用于 MySQL 的 AUTO_INCREMENT 或 Oracle 的 SEQUENCE[^1]。 --- #### UUID 主键生成 如果希望使用 UUID 作为主键，则可以选择以下配置： ```java @TableId(type = IdType.UUID) private String id; ``` 该策略会自动为新记录生成一个基于 UUID 的字符串型主键[^2]。 --- #### 雪花算法 (Snowflake Algorithm) MyBatis Plus 提供了内置的雪花算法用于分布式环境下的唯一 ID 生产。可通过以下方式启用： ```java @TableId(type = IdType.ASSIGN_ID) private Long id; ``` 这种策略适合高并发场景下生成全局唯一的长整型主键[^3]。 --- #### 自定义主键值 (手动输入) 有时开发者可能需要完全控制主键值的生成逻辑，在这种情况下可以设置主键类型为 `INPUT` 并自行赋值给主键属性： ```java @Data @KeySequence(value = "SEQ_ACL_ROLE", clazz = Integer.class) // 定义使用的 Sequence 名称 public class AclUser implements Serializable { private static final long serialVersionUID = 780903014942735924L; @TableId(value = "ID", type = IdType.INPUT) private Integer id; } ``` 上述代码片段展示了如何利用 `@KeySequence` 注解绑定数据库中的序列对象，并将其应用于主键生成过程。需要注意的是，这种方法依赖于底层数据库的支持（如 PostgreSQL 和 Oracle），因此需确保目标表已创建相应的序列资源。 --- #### 综合示例 假设有一个名为 `user_info` 的数据表以及对应的 Java 实体类 `UserInfo`，以下是完整的主键配置案例： ```java import com.baomidou.mybatisplus.annotation.IdType; import com.baomidou.mybatisplus.annotation.TableId; import org.springframework.data.annotation.KeySequence; @Data @KeySequence(value = "USER_INFO_SEQ") // 关联数据库中的 USER_INFO_SEQ 序列 public class UserInfo { @TableId(value = "id", type = IdType.INPUT) private Long id; // 手动填充或由 KeySequence 自动生成 private String username; private String email; } ``` 在此基础上，框架会在保存操作前调用指定的序列获取下一个可用编号并赋予至 `id` 属性。 --- ### 注意事项 - 如果采用 `ASSIGN_ID` 类型，则无需额外编码即可完成高效可靠的主键分配。 - 对于复杂业务需求或者跨平台兼容考虑，请优先选用标准化方案而非硬编码固定规则。 - 当项目涉及多套异构存储引擎时应审慎评估各选项优劣再做决定[^4]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值