别乱用UUID了,自增ID和UUID性能差距你测过吗?
yuyutoo 2024-10-18 12:10 1 浏览 0 评论
准备表&数据
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='用户表';
500w级数据测试
# 自增id为主键的表
mysql> select count(1) from UC_USER;
+----------+
| count(1) |
+----------+
| 5720112 |
+----------+
1 row in set (0.00 sec)
# uuid为主键的表
mysql> select count(1) from UC_USER_PK_VARCHAR_1;
+----------+
| count(1) |
+----------+
| 5720112 |
+----------+
1 row in set (1.91 sec)
1、录入500W数据,自增ID节省一半磁盘空间
占据的空间容量来看,自增ID比UUID小一半左右。
2、单个数据走索引查询,自增id和uuid相差不大
3、范围like查询,自增ID性能优于UUID
4、写入测试,自增ID是UUID的4倍
5、备份和恢复,自增ID性能优于UUID
500W总结
在500W记录表的测试下:
1、普通单条或者20条左右的记录检索,uuid为主键的相差不大几乎效率相同;
2、 但是范围查询特别是上百成千条的记录查询,自增id的效率要大于uuid;
3、在范围查询做统计汇总的时候,自增id的效率要大于uuid;
4、在存储上面,自增id所占的存储空间是uuid的1/2;
5、在备份恢复上,自增ID主键稍微优于UUID。
1000W总结
在1000W记录表的测试下:
1、普通单条或者20条左右的记录检索,自增主键效率是uuid主键的2到3倍;
2、但是范围查询特别是上百成千条的记录查询,自增id的效率要大于uuid;
3、在范围查询做统计汇总的时候,自增id主键的效率是uuid主键1.5到2倍;
4、在存储上面,自增id所占的存储空间是uuid的1/2;
5、在写入上面,自增ID主键的效率是UUID主键的3到10倍,相差比较明显,特别是update小范围之内的数据上面。
6、在备份恢复上,自增ID主键稍微优于UUID。
自增ID主键+步长,适合中等规模的分布式场景
在每个集群节点组的master上面,设置(auto_increment_increment),让目前每个集群的起始点错开 1,步长选择大于将来基本不可能达到的切分集群数,达到将 ID 相对分段的效果来满足全局唯一的效果。
- 优点:实现简单,后期维护简单,对应用透明;
- 缺点:第一次设置相对较为复杂,因为要针对未来业务的发展而计算好足够的步长。
UUID,适合小规模的分布式环境
对于InnoDB这种聚集主键类型的引擎来说,数据会按照主键进行排序,由于UUID的无序性,InnoDB会产生巨大的IO压力,而且由于索引和数据存储在一起,字符串做主键会造成存储空间增大一倍。
在存储和检索的时候,innodb会对主键进行物理排序,这对auto_increment_int是个好消息,因为后一次插入的主键位置总是在最后。
但是对uuid来说,这却是个坏消息,因为uuid是杂乱无章的,每次插入的主键位置是不确定的,可能在开头,也可能在中间,在进行主键物理排序的时候,势必会造成大量的 IO操作影响效率,在数据量不停增长的时候,特别是数据量上了千万记录的时候,读写性能下降的非常厉害。
- 优点:搭建比较简单,不需要为主键唯一性的处理。
- 缺点:占用两倍的存储空间(在云上光存储一块就要多花2倍的钱),后期读写性能下降厉害。
相关推荐
- Google Chrome 100 Beta发布 用户代理字符串作用开始逐渐降低
-
GoogleChrome和MozillaFirefox都在迅速接近100版本,这有可能破坏一些错误识别浏览器版本的网站(可能导致访问不正常,这有点类似于众所周知的千年虫)。两种浏览器都在研究可能的...
- 如何在Chrome,Edge,Safari和Firefox中更改用户代理
-
无论您是SEO,营销人员还是Web开发人员,通常都可能需要更改浏览器的用户代理以测试其他内容。例如,您正在运行特定于MAC-OS的活动。要确定您的广告系列是否正常运行并且未针对Linux用户,更改浏览...
- Mozilla正在测试新的浏览器UserAgent
-
Mozilla最近发布了一个实验项目来测试3位数的UserAgent版本“Firefox/100.0”会不会让一些网站停止正常工作。浏览器UserAgent是一串字符串,里面包含了浏览器的软件信息,版...
- 爬虫与User-Agent
-
什么是User-Agent呢?User-Agent是一个特殊字符串头,被广泛用来标示浏览器客户端的信息,使得服务器能识别客户机使用的操作系统和版本,CPU类型,浏览器及版本,浏览器的渲染引擎,浏览器...
- 让你的浏览器充满魔性——User Agent Switche
-
对于前端人员,闲暇时就会研究各种插件,今天我就分享UserAgentSwitcher在Firefox和Chrome的使用情况。一、Firefox浏览器UserAgentSwitcher作为火...
- 亚马逊账号运营安全-浏览器指纹识别之User-Agent开篇
-
UA包含了一个约定的特征字符串。主要是面向受访问网络表明自己的操作系统,软件开发商,版本,应用类型等信息。这是一种主动暴露信息的方式。我们来看关于UA的简单语法定义:User-Agent:<p...
- 【每日学习】Python爬虫之伪装浏览器User-Agent
-
【主题】Python爬虫之伪装浏览器原理【分析】1.创建自定义请求对象的目的,对抗网站的反爬虫机制2.反爬虫机制1:判断用户是否是浏览器访问(User-Agent)3.对抗措施1:伪装浏览器进行访问【...
- 亚马逊账号运营安全-浏览器指纹识别之User-Agent二篇
-
大家好,上一篇亚马逊账号运营安全-浏览器指纹识别之User-Agent开篇为大家阐述了原理。下面是作者为大家整理的其他几个主流浏览器的UA配置。一下都是Windows1064X系统下整理。Chrom...
- 常见的爬虫UserAgent
-
通过前面的文章我们知道,UserAgent(用户代理)是HTTP请求的一部分,用于告诉服务器发起请求的客户端类型和属性等信息。同时,也了解了常见的UserAgent。...
- HTTP请求头之User-Agent
-
什么是User-AgentUser-Agent中文名为用户代理,简称UA,...
- 你想不到的浏览器流氓史!那些奇怪的User-Agent,是这么来的...
-
平时我们用chrome浏览器做开发测试。Chrome的Useragent字段怎么这么奇怪?...
- 谷歌宣布 Chrome 将逐步停止支持 User Agent
-
谷歌近日宣布将放弃对Chrome浏览器中用户代理字符串(User-AgentString)的支持。取而代之的是,Chrome将提供一个名为“客户端提示(ClientHints)”的新API...
- 数据采集-用户代理(useragent)
-
UserAgent分类:PC端的UserAgent。移动端UserAgent。使用UserAgent的必要性:在写python网络爬虫程序的时候,经常需要修改UserAgent,有很多原因,罗列几个如...
- 如何获取当前浏览器的useragent
-
有时候,我们需要得到浏览器的useragent,从而再进行后面的一系列判断,返回不同的值。网上有说,在浏览器地址栏输入:javascript:alert(navigator.userAgent)这种方...
- User Agent 解析:它是什么以及如何修改
-
什么是UserAgent?UserAgent,简称UA,是一个使服务器能够识别用户使用的浏览器类型、版本以及运行浏览器的操作系统等信息的字符串。它作为浏览器请求头部信息的一部分发送给服务器,以便服务...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- mybatis plus (70)
- scheduledtask (71)
- css滚动条 (60)
- java学生成绩管理系统 (59)
- 结构体数组 (69)
- databasemetadata (64)
- javastatic (68)
- jsp实用教程 (53)
- fontawesome (57)
- widget开发 (57)
- vb net教程 (62)
- hibernate 教程 (63)
- case语句 (57)
- svn连接 (74)
- directoryindex (69)
- session timeout (58)
- textbox换行 (67)
- extension_dir (64)
- linearlayout (58)
- vba高级教程 (75)
- iframe用法 (58)
- sqlparameter (59)
- trim函数 (59)
- flex布局 (63)
- contextloaderlistener (56)