为啥不能用uuid做MySQL的主键?
在 MySQL 中设计表的时候,MySQL 官方推荐不要使用 uuid 或者不连续不重复的雪花 id(long 形且唯一,单机递增),而是推荐连续自增的主键 id,官方的推荐是 auto_increment。

那么为什么不建议采用 uuid,使用 uuid 究竟有什么坏处?本问我们从以下几个部分来分析这个问题,探讨一下内部的原因:
MySQL 程序实例
使用 uuid 和自增 id 的索引结构对比
总结
MySQL 程序实例
要说明这个问题,我们首先来建立三张表,分别是:
user_auto_key
user_uuid
user_random_key
他们分别表示自动增长的主键,uuid 作为主键,随机 key 作为主键,其他我们完全保持不变。
id 自动生成表:

用户 uuid 表:


光有理论不行,直接上程序,使用 Spring 的 jdbcTemplate 来实现增查测试。
技术框架:Spring Boot+jdbcTemplate+junit+hutool,程序的原理就是连接自己的测试数据库,然后在相同的环境下写入同等数量的数据,来分析一下 insert 插入的时间来进行综合其效率。
package?com.wyq.mysqldemo;
import?cn.hutool.core.collection.CollectionUtil;
import?com.wyq.mysqldemo.databaseobject.UserKeyAuto;
import?com.wyq.mysqldemo.databaseobject.UserKeyRandom;
import?com.wyq.mysqldemo.databaseobject.UserKeyUUID;
import?com.wyq.mysqldemo.diffkeytest.AutoKeyTableService;
import?com.wyq.mysqldemo.diffkeytest.RandomKeyTableService;
import?com.wyq.mysqldemo.diffkeytest.UUIDKeyTableService;
import?com.wyq.mysqldemo.util.JdbcTemplateService;
import?org.junit.jupiter.api.Test;
import?org.springframework.beans.factory.annotation.Autowired;
import?org.springframework.boot.test.context.SpringBootTest;
import?org.springframework.util.StopWatch;
import?java.util.List;
@SpringBootTest
class?MysqlDemoApplicationTests?{
????@Autowired
????private?JdbcTemplateService?jdbcTemplateService;
????@Autowired
????private?AutoKeyTableService?autoKeyTableService;
????@Autowired
????private?UUIDKeyTableService?uuidKeyTableService;
????@Autowired
????private?RandomKeyTableService?randomKeyTableService;
????@Test
????void?testDBTime()?{
????????StopWatch?stopwatch?=?new?StopWatch("执行sql时间消耗");
????????/**
?????????*?auto_increment?key任务
?????????*/
????????final?String?insertSql?=?"INSERT?INTO?user_key_auto(user_id,user_name,sex,address,city,email,state)?VALUES(?,?,?,?,?,?,?)";
????????List<UserKeyAuto>?insertData?=?autoKeyTableService.getInsertData();
????????stopwatch.start("自动生成key表任务开始");
????????long?start1?=?System.currentTimeMillis();
????????if?(CollectionUtil.isNotEmpty(insertData))?{
????????????boolean?insertResult?=?jdbcTemplateService.insert(insertSql,?insertData,?false);
????????????System.out.println(insertResult);
????????}
????????long?end1?=?System.currentTimeMillis();
????????System.out.println("auto?key消耗的时间:"?+?(end1?-?start1));
????????stopwatch.stop();
????????/**
?????????*?uudID的key
?????????*/
????????final?String?insertSql2?=?"INSERT?INTO?user_uuid(id,user_id,user_name,sex,address,city,email,state)?VALUES(?,?,?,?,?,?,?,?)";
????????List<UserKeyUUID>?insertData2?=?uuidKeyTableService.getInsertData();
????????stopwatch.start("UUID的key表任务开始");
????????long?begin?=?System.currentTimeMillis();
????????if?(CollectionUtil.isNotEmpty(insertData))?{
????????????boolean?insertResult?=?jdbcTemplateService.insert(insertSql2,?insertData2,?true);
????????????System.out.println(insertResult);
????????}
????????long?over?=?System.currentTimeMillis();
????????System.out.println("UUID?key消耗的时间:"?+?(over?-?begin));
????????stopwatch.stop();
????????/**
?????????*?随机的long值key
?????????*/
????????final?String?insertSql3?=?"INSERT?INTO?user_random_key(id,user_id,user_name,sex,address,city,email,state)?VALUES(?,?,?,?,?,?,?,?)";
????????List<UserKeyRandom>?insertData3?=?randomKeyTableService.getInsertData();
????????stopwatch.start("随机的long值key表任务开始");
????????Long?start?=?System.currentTimeMillis();
????????if?(CollectionUtil.isNotEmpty(insertData))?{
????????????boolean?insertResult?=?jdbcTemplateService.insert(insertSql3,?insertData3,?true);
????????????System.out.println(insertResult);
????????}
????????Long?end?=?System.currentTimeMillis();
????????System.out.println("随机key任务消耗时间:"?+?(end?-?start));
????????stopwatch.stop();
????????String?result?=?stopwatch.prettyPrint();
????????System.out.println(result);
????}
程序写入结果
user_key_auto 写入结果:

user_random_key 写入结果:

user_uuid 表写入结果:

效率测试结果

在已有数据量为 130W 的时候:我们再来测试一下插入 10w 数据,看看会有什么结果:

可以看出在数据量 100W 左右的时候,uuid 的插入效率垫底,并且在后序增加了 130W 的数据,uuid 的时间又直线下降。
时间占用量总体可以打出的效率排名为:auto_key>random_key>uuid。
uuid 的效率最低,在数据量较大的情况下,效率直线下滑。那么为什么会出现这样的现象呢?带着疑问,我们来探讨一下这个问题:
使用 uuid 和自增 id 的索引结构对比
使用自增 id 的内部结构

自增的主键的值是顺序的,所以 InnoDB 把每一条记录都存储在一条记录的后面。
当达到页面的最大填充因子时候(InnoDB 默认的最大填充因子是页大小的 15/16,会留出 1/16 的空间留作以后的修改)。
使用 uuid 的索引内部结构

使用自增 id 的缺点
那么使用自增的 id 就完全没有坏处了吗?并不是,自增 id 也会存在以下几点问题:
①别人一旦爬取你的数据库,就可以根据数据库的自增 id 获取到你的业务增长信息,很容易分析出你的经营情况。
②对于高并发的负载,InnoDB 在按主键进行插入的时候会造成明显的锁争用,主键的上界会成为争抢的热点,因为所有的插入都发生在这里,并发插入会导致间隙锁竞争。
③Auto_Increment 锁机制会造成自增锁的抢夺,有一定的性能损失。
附:Auto_increment的锁争抢问题,如果要改善需要调优 innodb_autoinc_lock_mode 的配置。
总结
作者:Yrion
编辑:陶家龙
出处:cnblogs.com/wyq178/p/12548864.html

精彩文章推荐:
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/
关注网络尖刀微信公众号随时掌握互联网精彩
- 1 中国经济向世界提供“机遇清单” 7904399
- 2 朱元璋换帅照后明孝陵火了 7807947
- 3 水银体温计将禁产 有网友囤货100支 7714251
- 4 2025这些“经济”持续成长壮大 7618221
- 5 近8000吨车厘子来了 7521723
- 6 老人接孙女从认不出到相拥大哭 7426475
- 7 冯提莫自曝癌症复发并转移 7329189
- 8 美国女子熟睡时被医生男友喂堕胎药 7231773
- 9 西班牙女员工连续提前到岗被开除 7138162
- 10 寒潮来袭!多地气温将创下半年来新低 7048174







51CTO技术栈
