惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
Simon Willison's Weblog
Simon Willison's Weblog
Microsoft Security Blog
Microsoft Security Blog
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
F
Fortinet All Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
A
About on SuperTechFans
Last Week in AI
Last Week in AI
月光博客
月光博客
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
Martin Fowler
Martin Fowler
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
C
Check Point Blog
U
Unit 42
The Register - Security
The Register - Security
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Hugging Face - Blog
Hugging Face - Blog
阮一峰的网络日志
阮一峰的网络日志
V
Visual Studio Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
D
DataBreaches.Net
WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
H
Hacker News: Front Page
Recent Announcements
Recent Announcements
C
CXSECURITY Database RSS Feed - CXSecurity.com
Latest news
Latest news
小众软件
小众软件
P
Palo Alto Networks Blog
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest
S
Secure Thoughts
Scott Helme
Scott Helme
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Threat Research - Cisco Blogs
P
Proofpoint News Feed
M
MIT News - Artificial intelligence
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google DeepMind News
Google DeepMind News
Recorded Future
Recorded Future
O
OpenAI News
S
Securelist
云风的 BLOG
云风的 BLOG
H
Help Net Security
T
Troy Hunt's Blog

博客园 - PointNet

log4j2发送消息至Kafka log4j2自定义Appender(输出到文件/RPC服务中) log4j 不同模块输出到不同的文件 shell之磁盘容量检查,配合crontab可以定时清理磁盘 spring注解之@profile How to do conditional auto-wiring in Spring? MyBatis传入参数为集合 list 数组 map写法 Spring Boot @Autowired 没法自动注入的问题 dom4j解析xml字符串实例 spring自动注入是单例还是多例?单例如何注入多例? Spring中Bean的五个作用域 【总结】瞬时高并发(秒杀/活动)Redis方案 浅谈分布式事务 基于Redis实现分布式锁 MySQL事务隔离级别详解 Redis学习手册(Sorted-Sets数据类型) Redis的快照持久化-RDB与AOF Redis - 事务 ArrayList、Vector、HashMap、HashTable、HashSet的默认初始容量、加载因子、扩容增量
mysql5.5 uuid做主键与int做主键的性能实测
PointNet · 2017-09-28 · via 博客园 - PointNet

偶然的机会,得知mysql主键的类型采用 varchar 存UUID 的查询性能没有int型做主键好。网上查询大量资料,都是停留在理论上的,因此,自己写了代码进行实测,以下结果仅供参考,不具备权威性。

三个表的字段,除了主键ID 分别采用varchar,bigint 和自动增长bigint不同外,其他三个字段都为 varchar 36位

数据库:mysql5.5

表类型:InnoDB

数据量:100W条

第一种情况:

主键采用uuid 32位。

运行查询语句1:SELECT COUNT(id) FROM test_varchar;

运行查询语句2:SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b';

运行查询语句3:SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';

语句1消耗时间平均为:2.7秒;

语句2消耗时间平均为:3秒;

语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

第二种情况:

主键采用bigint,使用uuid_short()产生数据,数据为有序列的纯数字(22461015967875697)。(其相当于自动增长,只是固定的基数值较大而已。)

运行查询语句1:SELECT COUNT(id) FROM test_long;

运行查询语句2:SELECT * FROM test_long WHERE vname='d7f28a24-b053-11e1-96aa-002655b28d7b';

运行查询语句3:SELECT * FROM  test_long WHERE id='22461015967875702';

语句1消耗时间平均为:1.2秒;

语句2消耗时间平均为:1.40秒;

语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

第三种情况:

运行查询语句1:SELECT COUNT(id) FROM test_int;

运行查询语句2:SELECT * FROM test_int WHERE vname='c80f8427-b059-11e1-96aa-002655b28d7b';

运行查询语句3:SELECT * FROM test_int WHERE id=900000;

主键采用mysql自带的自动增长,数据为纯数字(1,2,3,4,5……)。

查询语句1消耗时间平均为:1.07秒;

查询语句2消耗时间平均为:1.31秒;

查询语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

总结:由此可见,mysql InnoDB 主键采用自动增长性能较高。

笔者自语:平时的项目开发,sql语句的条件里有ID的,占多数,没有的占少数。虽然以上的测试表明只要条件语句里有主键ID,主键类型不一样,查询时间完全一样。但是,你不能保证你的项目中所有sql语句的条件里都有ID,因此…………主键的类型该采用哪种,相信各位看官已经明白。

---------------------------------------------------------华丽的分割线----------------------------------------------------------

数据库:mysql5.5

表类型:MyISAM

数据量:100W条

为了少写一些字,节省时间,此测试所使用的表和sql语句同上,此处只记录消耗时间。

第一种情况:

主键采用uuid 32位。

语句1消耗时间平均为:0秒;

语句2消耗时间平均为:0.53秒;

语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

第二种情况:

主键采用bigint,使用uuid_short()产生数据,数据为有序列的纯数字(22461015967875697)。(其相当于自动增长,只是固定的基数值较大而已。)

语句1消耗时间平均为:0秒;

语句2消耗时间平均为:0.51秒;

语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

第三种情况:

主键采用mysql自带的自动增长,数据为纯数字(1,2,3,4,5……)。

语句1消耗时间平均为:0秒;

语句2消耗时间平均为:0.48秒;

语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)

总结:由此可见,mysql MyISAM 主键采用自动增长性能比其他有微弱的优势。测试数据为100w,如果是1000W 1亿,我想这个优势会拉大,如果你还有外键关联查询,这个优势就更明显了。当然,如果你设计的系统,数据量还没有超过100W,你用啥主键类型都无所谓。我测试电脑是笔记本,如果是专业的服务器,估计100W条,mysql MyISAM 的这些测试,根本都测不出来时间差。

大总结:本来是要测mysql主键类型不同,查询效率的差别的,怎么写到最后,感觉像是在测mysql InnoDB和MyISAM的优劣了,无限纠结中……,有时间测下oracle!!