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

最新推荐文章于 2024-06-27 09:20:12 发布
最新推荐文章于 2024-06-27 09:20:12 发布
阅读量1w 收藏 3
点赞数 1
分类专栏： 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；

林震南
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
数据库主键到底是用自增长好还是UUID好
关注我！带你一路 "狂飙" 到底！
08-06 2489
各位同学好，今天给大家讲一下MySQL数据库在设计主键时，应该使用哪种数据类型。我们知道，咱们在设计数据库时，主键是必须设置的。一般情况下，咱们都会选择使用主键自增或者UUID这两种主键策略。那么这两个哪种更好呢？我们应该使用哪一种呢，今天就请大家跟老徐来一起来学习一下吧。
深入分析mysql为什么不推荐使用uuid或者雪花id作为主键
12-14
前言：在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处？...
mysql 使用uuid主键_MySQL UUID和主键（二十二）
weixin_39769183的博客
11-22 781
本教程将向您介绍MySQL UUID，并演示如何将其用作表的主键(PK)，并讨论将其用作主键的优缺点。MySQL UUID简介UUID代表通用唯一标识符。UUID是基于”RFC 4122“通用唯一标识符(UUID)URN命名空间”)定义的。UUID被设计为在空间和时间全球独一无二的数字。 预期两个UUID值是不同的，即使它们在两个独立的服务器上生成。在MySQL中，UUID值是一个128位的数字，...
MySQL主键：自增ID与UUID的选择
最新发布
My_wife_QBL的博客
06-27 301
在设计数据库表时，选择合适的主键类型是一个重要的决策。MySQL中，主键的选择通常在自增ID和UUID之间进行权衡。本文将探讨这两种主键类型的优缺点，以及在不同场景下的适用性。
mysql uuid 主键_将大型（UUID）作为MySQL表主键的最佳方式
weixin_32561885的博客
01-18 139
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 1073
数据库使用自增ID好还是UUID好？为什么？
主键使用自增ID还是UUID?
IUUUUUUU的博客
04-02 203
主键使用自增ID还是UUID
spring boot整合mybatis利用Mysql实现主键UUID的方法
08-27
在Spring Boot项目中，整合MyBatis并利用MySQL实现主键UUID是一种常见的需求，尤其是在分布式系统中，为了保证数据的一致性和唯一性。UUID（Universally Unique Identifier）是一种全局唯一的标识符，它由128位数字...
浅谈MySQL中的自增主键用完了怎么办
12-14
面试官:”用过mysql吧，你们是用自增主键还是UUID？” 你:”用的是自增主键” 面试官:”为什么是自增主键？” 你:”因为采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla…” 面试官:”那自增主键...
为什么说InnoDB必须要有主键并且推荐使用自增整型主键呢？
01-20
总的来说，InnoDB必须要有主键以支持其数据组织和查询效率，而自增整型主键因其存储效率和比较速度而被推荐。但同时，设计时需注意主键的大小，避免造成不必要的空间浪费，确保数据库性能最大化。
mysql自增id超大问题的排查与解决
09-09
MySQL中的自增ID是表设计中的一个重要元素，特别是在需要唯一标识每条记录的场景下。然而，当自增ID超出其定义的最大值时，就会出现所谓的“超大问题”。这个问题通常发生在频繁进行删除和插入操作的表上，尤其是在...
laravel-optikey:在Laravel中使用UUID或Ulid作为可选键或主键
05-24
在Laravel中使用UUID或Ulid作为可选键或主键。 composer require riipandi/laravel-optikey 该软件包添加了一个非常简单的特征，可以为您的模型自动生成UUID或Ulid。 快速开始 更新您的架构 首先，您需要在迁移中...
mysql雪花算法生成唯一整型ID主键的实现方法
03-07
MySQL 雪花算法生成唯一整型ID主键的实现主要针对大数据环境下，需要大量生成全局唯一ID的需求。雪花算法是一种分布式ID生成策略，由Twitter开源，其设计目标是在分布式系统中生成具有全局唯一性、有序性和高并发性...
mysql如何让自增id归0解决方案
12-15
在数据库设计中，合理规划主键和自增ID的使用，对于数据管理和系统的高效运行至关重要。在面对类似问题时，除了直接重置自增ID，也可以考虑是否可以通过其他方式优化，如使用UUID或其他分布式ID生成策略，来避免ID过...
Java实现产生随机字符串主键的UUID工具类
08-29
UUID（ Universally Unique Identifier，通用唯一标识符）是一种常用的标识符格式，由32个十六进制数字组成，分为五部分：时钟序列号、时钟序列号、节点ID、随机数和时间戳。 Java实现产生随机字符串主键的UUID...
基于django 的orm中非主键自增的实现方式
09-16
然而，在某些应用场景中，可能需要额外的字段也具备自增特性，而这些字段并不适合作为主键使用。例如，某个实体拥有一个全局唯一的UUID作为主键，但同时还需要一个按顺序排列的编号字段。本文将详细介绍如何在Django...
mysql的联合主键与复合主键区别
拿着核武器的程序员的博客
10-30 4504
复合主键就是指你表的主键含有一个以上的字段组成 。 例如； 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 4380
14、主键一般用自增ID还是UUID？ （1）自增ID： 使用自增ID的好处： 字段长度较 UUID 会小很多。 数据库自动编号，按顺序存放，利于检索 无需担心主键重复问题 使用自增ID的缺点： 因为是自增，在某些业务场景下，容易被其他人查到业务量。 发生数据迁移时，或者表合并时会非常麻烦 在高并发的场景下，竞争自增锁会降低数据库的吞吐能力 （2）UUID：通用唯一标识码，UUID是基于当前时间、计数器和硬件标识等数据计算生成的。 使用UUID的优点： 唯一标识，不用考虑重复问题，在数据拆分
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
zhanggx512的博客
08-13 625
https://blog.csdn.net/mchdba/article/details/52336203
msql中自增的主键和uuid主键的区别
03-29
1. 自增主键：在 MySQL 中，自增主键是一个整数类型，每次自动递增，保证了每个记录都有唯一的主键值。自增主键可以方便地进行排序和索引操作，但是当数据量较大时，可能会出现主键重复的情况，需要进行手动处理。 2. UUID 主键：UUID 是一种全局唯一的标识符，可以确保每个记录都有唯一的主键值。UUID 主键可以避免主键冲突的问题，但是由于 UUID 是一个字符串类型，所以在进行排序和索引操作时会比自增主键慢。 综上所述，自增主键适合数据量较小且需要进行排序和索引操作的情况，而 UUID 主键适合需要保证主键唯一性的情况，但是可能会影响性能。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值