Mysql为什么不用uuid作为表的主键

竹下星空

于 2018-11-29 10:34:52 发布

阅读量3k

点赞数

CC 4.0 BY-SA版权

分类专栏： mysql

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/shidebin/article/details/84617865

mysql 专栏收录该内容

8 篇文章

订阅专栏

探讨UUID生成速率低下问题，特别是在多线程环境下，以及UUID作为InnoDB主键时引发的性能下降。分析原因包括SecureRandom依赖、B+树叶子节点分裂及缓存效率降低。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

UUID生成速率低下

Java的UUID依赖于SecureRandom.nextBytes方法，而SecureRandom又依赖于操作系统提供的随机数源，在Linux系统下，它的默认依赖是/dev/random，而这个源是阻塞的。最可怕的是，这个nextBytes方法还是一个synchronized方法，也就是说，如果多线程调用UUID，生成速率不升反降。

测试结果：在一台64线程的服务器上，调用UUID.randomUUID方法，生成一千万个uuid平均耗时在130s，tps不到8w

UUID主键在innodb中会引发性能问题

a. innodb中的主键索引也是聚集索引，如果插入的数据是顺序的，那么b+树的叶子基本都是满的，缓存也可以很好的发挥作用。如果插入的数据是完全无序的，那么叶子节点会频繁分裂，缓存也基本无效了。这会减少tps

b. uuid占用的空间较大

UUID完全没有意义，如果有一个主键是全局自增的，那么数据排列顺序就是数据的插入顺序

评论 2

被折叠的条评论为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

成就一亿技术人!

hope_wisdom

发出的红包

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额 0

抵扣说明：

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