登录
首页 >  数据库 >  MySQL

MySQL 自增 VS UUID

来源:SegmentFault

时间:2023-02-25 10:33:40 299浏览 收藏

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的,希望这篇《MySQL 自增 VS UUID》对你有很大帮助!欢迎收藏,分享给更多的需要的朋友学习~

引言

简介

编写开源组件,自然一切都要采用最佳实践。

在第一步,设计数据表时就遇到了问题,过去的数据表中,一直采用

SELECT UUID() as UUID

image.png

UUID
的格式如下:

32
16
进制数字,以
-
作为分隔符,格式为
8-4-4-4-12
,共计
36
个字符。

853a7583-3bf9-11ea-8dc9-f48e38f0f826

$${16}^{32}\approx{3.4}\times{10}^{38}$$

这个具体怎么生成出来的就不研究了,了解全局唯一即可。

ps:

segmentfault
latex
公式还挺好使!

探究

对比

参考问题:The differences between INT and UUID in MySQL - StackOverflow

参考问题:UUID performance in MySQL - StackOverflow

参考文章:美团技术分享:深度解密美团的分布式ID生成算法 - SegmentFault

如果选用了自增

INT
作为主键,会在特定数据库与特定数据表内返回唯一的
INT
值,但是并不是全局唯一的,如果该数据库被导入到其他的数据库,就会发生主键冲突。

UUID优点

性能非常高:本地生成,无网络消耗。

UUID缺点

不易于存储:

UUID
长度
36
个字符,太长。

信息不安全:

UUID
算法基于
MAC
地址生成,可能会造成
MAC
地址泄露。

MySQL
官方建议主键越短越好。且在
InnoDB
引擎下,
UUID
的无序性会严重影响性能。

总结

看了好多关于两者对比的文章,大多数都是根本没有经过实际业务考验的纸上谈兵,但是微信、美团的技术分享还是很说明问题的。

精简下来就是

UUID
全局唯一,但其性能不适合大数据与高并发场景。

在数据库层面,小业务,如果不考虑数据迁移与分布式,

INT
自增足够了。大业务,分布式、高并发、大数据,
UUID
虽然能保证唯一,但性能不佳,仍需设计自定义的
ID
算法。

发现美团的

ID
算法是开源的,感谢美团:Leaf - Github

到这里,我们也就讲完了《MySQL 自增 VS UUID》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于mysql的知识点!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>