大家好,我是冰河~~
今天给大家带来一篇关于MySQL的技术文,这也是我对MySQL使用UUID做主键与int数字做主键做的性能压测。
之前,总有小伙伴问我:为何使用UUID做MySQL的主键,MySQL性能会比较低。之前我也跟大家基于MySQL的底层数据结构讨论了为何使用UUID做主键性能比较低下。
今天,我们就一起基于MySQL 5.7做一个实际的主键性能压测。让大家切实感受下使用UUID做MySQL的主键和int数字做MySQL的主键,性能到底有多少差异。
环境准备
在MySQL 5.7中分别创建三张数据表:
- test_varchar:以UUID作为主键。
- test_long:以bigint作为主键。
- test_int:以int作为主键。
三个表的字段,除了主键ID 分别采用varchar,bigint 和自动增长int不同外,其他三个字段都为 varchar 36位
另外,建表时使用InnoDB存储引擎,并且向数据库中插入100W条数据,用以测试。
InnoDB压测情况
压测信息
- 数据库:MySQL 5.7
- 表类型:InnoDB
- 数据量:100W条
主键采用uuid 32位
运行查询语句1:
SELECTCOUNT(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
主键采用bigint,使用uuid_short()产生数据,数据为有序列的纯数字(22461015967875697)。(其相当于自动增长,只是固定的基数值较大而已。)
运行查询语句1:
SELECTCOUNT(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)
主键采用自增int
运行查询语句1:
SELECTCOUNT(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 主键采用自动增长性能较高,但是在技术工作中,能否直接使用自增int类型的数字作为MySQL的主键,大家需要根据具体需求确定。
MyISAM压测情况
压测信息
- 数据库:MySQL 5.7
- 表类型:MyISAM
- 数据量:100W条
注意:此处测试所使用的表和SQL语句同上,此处只记录消耗时间。
主键采用uuid 32位
主键采用uuid 32位。
- 语句1消耗时间平均为:0秒;
- 语句2消耗时间平均为:0.53秒;
- 语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)
主键采用bigint
主键采用bigint,使用uuid_short()产生数据,数据为有序列的纯数字(22461015967875697)。(其相当于自动增长,只是固定的基数值较大而已。)
- 语句1消耗时间平均为:0秒;
- 语句2消耗时间平均为:0.51秒;
- 语句3消耗时间平均为:0秒;(多方测试,条件里只要有主键ID,查询速度毫秒级都显示000。测试的ID值,有前一百条的,也有后90多万条的。查询时间完全一样,毫秒级都为000)
主键采用自增int
主键采用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数据库的?(建议收藏)》
- 《我用多线程进一步优化了亿级流量电商业务下的海量数据校对系统,性能再次提升了200%!!(全程干货,建议收藏)》
- 《我用多线程优化了亿级流量电商业务下的海量数据校对系统,性能直接提升了200%!!(全程干货,建议收藏)》
- 《我用10张图总结出了这份并发编程最佳学习路线!!(建议收藏)》
- 《高并发场景下一种比读写锁更快的锁,看完我彻底折服了!!(建议收藏)》
- 《全网最全性能优化总结!!(冰河吐血整理,建议收藏)》
- 《三天撸完了MyBatis,各位随便问!!(冰河吐血整理,建议收藏)》
- 《奉劝那些刚参加工作的学弟学妹们:要想进大厂,这些并发编程知识是你必须要掌握的!完整学习路线!!(建议收藏)》
- 《奉劝那些刚参加工作的学弟学妹们:要想进大厂,这些核心技能是你必须要掌握的!完整学习路线!!(建议收藏)》
- 《奉劝那些刚参加工作的学弟学妹们:这些计算机与操作系统基础知识越早知道越好!万字长文太顶了!!(建议收藏)》
- 《我用三天时间开发了一款老少皆宜的国民级游戏,支持播放音乐,现开放完整源代码和注释(建议收藏)!!》
- 《我是全网最硬核的高并发编程作者,CSDN最值得关注的博主,大家同意吗?(建议收藏)》
- 《毕业五年,从月薪3000到年薪百万,我掌握了哪些核心技能?(建议收藏)》
- 《我入侵了隔壁妹子的Wifi,发现。。。(全程实战干货,建议收藏)》
- 《千万不要轻易尝试“熊猫烧香”,这不,我后悔了!》
- 《清明节偷偷训练“熊猫烧香”,结果我的电脑为熊猫“献身了”!》
- 《7.3万字肝爆Java8新特性,我不信你能看完!(建议收藏)》
- 《在业务高峰期拔掉服务器电源是一种怎样的体验?》
- 《全网最全Linux命令总结!!(史上最全,建议收藏)》
- 《用Python写了个工具,完美破解了MySQL!!(建议收藏)》
- 《SimpleDateFormat类到底为啥不是线程安全的?(附六种解决方案,建议收藏)》
- 《MySQL 8中新增的这三大索引,直接让MySQL起飞了,你竟然还不知道!!(建议收藏)》
- 《撸完Spring源码,我开源了这个分布式缓存框架!!(建议收藏)》
- 《亿级流量高并发秒杀系统商品“超卖”了,只因使用的JDK同步容器中存在这两个巨大的坑!!(踩坑实录,建议收藏)》
- 《奉劝那些刚参加工作的学弟学妹们:要想学好并发编程,这些并发容器的坑是你必须要注意的!!(建议收藏)》
- 《公司的报表工具太难用,我三天撸了个Excel工具,运营小姐姐直呼太好用了,现已开源!!(建议收藏)》
- 《奉劝那些刚参加工作的学弟学妹们:要想进大厂,这些并发编程核心技能是你必须要掌握的!!(建议收藏)》
- 《阿里面试官:高并发大流量秒杀系统如何正确的解决库存超卖问题?(建议收藏)》
- 《Redis五大数据类型与使用场景汇总!!(含完整实战案例,建议收藏)》
好了,今天就到这儿吧,小伙伴们点赞、收藏、评论,一键三连走起呀,我是冰河,我们下期见~~
👇🏻 搜索下方 公众号 关注我👇🏻
版权归原作者 冰 河 所有, 如有侵权,请联系我们删除。