MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程

最新推荐文章于 2024-06-27 09:20:12 发布
最新推荐文章于 2024-06-27 09:20:12 发布
阅读量1.1k 收藏
点赞数
分类专栏： Mysql

【转载】一个开发同事做了一个框架，里面主键是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；

以上就是MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（500W单表）的内容，更多相关内容请关注PHP中文网（www.php.cn）！

zhenzhenup
关注
专栏目录
数据库主键到底是用自增长好还是UUID好
关注我！带你一路 "狂飙" 到底！
08-06 2514
各位同学好，今天给大家讲一下MySQL数据库在设计主键时，应该使用哪种数据类型。我们知道，咱们在设计数据库时，主键是必须设置的。一般情况下，咱们都会选择使用主键自增或者UUID这两种主键策略。那么这两个哪种更好呢？我们应该使用哪一种呢，今天就请大家跟老徐来一起来学习一下吧。
MySQL使用自增ID主键和UUID作为主键的优劣
qq_28807077的博客
12-16 334
原文链接：https://blog.csdn.net/qq_30108237/article/details/106856051
MySql 主键一般用自增ID还是UUID
书香水墨
12-15 4546
14、主键一般用自增ID还是UUID？ （1）自增ID： 使用自增ID的好处： 字段长度较 UUID 会小很多。 数据库自动编号，按顺序存放，利于检索 无需担心主键重复问题 使用自增ID的缺点： 因为是自增，在某些业务场景下，容易被其他人查到业务量。 发生数据迁移时，或者表合并时会非常麻烦 在高并发的场景下，竞争自增锁会降低数据库的吞吐能力 （2）UUID：通用唯一标识码，UUID是基于当前时间、计数器和硬件标识等数据计算生成的。 使用UUID的优点： 唯一标识，不用考虑重复问题，在数据拆分
MySQL主键：自增ID与UUID的选择
最新发布
My_wife_QBL的博客
06-27 389
在设计数据库表时，选择合适的主键类型是一个重要的决策。MySQL中，主键的选择通常在自增ID和UUID之间进行权衡。本文将探讨这两种主键类型的优缺点，以及在不同场景下的适用性。
在 Mysql 中， 主键应该使用自增还是 uuid ？
六等星的小宇宙
09-07 1401
这两种 id 哪一种比较好 ，我们在新建一张表的时候该怎么考虑主键的使用 ，今天就来好好的研究一下 。
mysql一主键uuid和自增的选择
weixin_70280523的博客
03-04 3948
MySQL主键
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
hfdgjjg的博客
01-27 613
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（500W单表）
hfdgjjg的博客
01-28 1804
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（500W单表）
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程 500W单表
hfdchhu的博客
11-05 926
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程 500W单表
mysql-主键设计
饮啖茶食个包
09-01 1089
文章目录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主键类型选择数据库自增主键，还是选择uuid的问题的理解
weixin_42206151的博客
05-08 1171
最近遇到了要选择String类型通过uuid设置实体类id好还是选择数字整型设置成数据库自增好的问题， 总结了一下两者的优缺点： 用数据库自增id的优点： 首先字段长度较uuid小很多，可以是bigint甚至是int类型，这对检索的性能会有所影响。我们平时数据库一般用的都是innodb引擎的表，这种表格检索数据的时候，哪怕走索引，也是先根据索引找到主键，然后由主键找到这条记录。所以主键的长度短的话...
MySQL 使用自增ID主键和UUID 作为主键的区别
weixin_33878457的博客
12-09 507
MySQL 使用自增ID主键和UUID 作为主键的区别http://www.360java.com/mysql/8421.html 转载于:https://blog.51cto.com/damaog/1881145
MySQL主键：自增id、UUID、雪花算法
weixin_46356448的博客
04-23 1255
视频可看： 动画讲解：为什么不能使用自增ID或者UUID做MySQL的主键，雪花算法生成的主键存在哪些问题_哔哩哔哩_bilibili自增主键的好处：写入效率高弊端：变通方式：不使用自增主键做数据分片，而使用业务数据的用户ID做数据分片，每个用户的数据都集中在一个库，可以做到更加的内聚。 UUID随机、无序，具有非常好的全局唯一性，但不推荐做MySQL主键。从MySQL的B+树原理看，一个page写满向下一个page写，要求下一个page的数据要大于上一个page的数据，现插入一个新数据，但U
数据库主键到底是用自增长（INT）好还是UUID好？
热门推荐
贾世鑫的博客
05-17 1万+
数据库主键到底是用自增长（INT）好还是UUID好？ 使用自增长做主键的优点： 1、很小的数据存储空间 2、性能最好 3、容易记忆使用自增长做主键的缺点： 1、如果存在大量的数据，可能会超出自增长的取值范围 2、很难（并不是不能）处理分布式存储的数据表，尤其是需要合并表的情况下 3、安全性低，因为是有规律的，容易被非法获取数据使用UUID做主键的优点： 1、它是独一无二的，出现重复的机会少 2、...
MySQL 数据表主键设计，选择自增 id 还是 UUID 还是雪花 id？
小楠的博客
03-31 7634
前言 在 MySQL 数据表的设计中，官方推荐我们不要使用 UUID 或者其他不连续不重复的 id，而是推荐使用连续自增的主键 id（auto_increment），那么为什么会这样建议呢，我们来简单地分析一下。 背景 随着现在许多项目都涉及到了分布式或者微服务，后续或多或少都会针对具体的服务需求对数据库进行拆分（分库分表），这里就会产生一个问题，拆分后的 id 该如何妥善处理？ 例如，在之前的业务中，所有的数据内容都是存放在同一张数据表中的，主键 id 都是自增的，这当然没有任何问题。但是当单表的数据量上
2020-09-08
weixin_41576919的博客
09-08 980
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 @[TOC](2020-09-08) 前言 提示：这里可以添加本文要记录的大概内容： 例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。 提示：以下是本篇文章正文内容，下面案例可供参考 #1 一、pandas是什么？ 示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。 #2 二、使用步骤 1.引入库 代..
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值