为什么MySQL不推荐使用uuid或者雪花id作为主键?

mysql雪花算法生成唯一整型ID主键的实现方法 mysql雪花算法生成唯一整型ID主键的实现方法,整型ID作为主键好处有很多,比如节省存储空间、插入和查询排序快、具有一定规律性(时间顺序)等。 立即下载
  1. 前言
    在MySQL中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?本篇博客我们就来分析这个问题,探讨一下内部的原因。

一、MySQL和程序实例

要说明这个问题,我们首先来建立三张表,分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变.根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样,然后测试一下表的插入速度和查询速度:

注:这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串18位长度的long值

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试

技术框架:springboot+jdbcTemplate+junit+hutool,程序的原理就是连接自己的测试数据库,然后在相同的环境下写入同等数量的数据,来分析一下insert插入的时间来进行综合其效率,为了做到最真实的效果,所有的数据采用随机生成,比如名字、邮箱、地址都是随机生成,程序已上传自gitee,地址在文底。

@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表任务开始"
);
        
longbegin
= 
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);
    }

在这里插入图片描述
!](https://img-blog.csdnimg.cn/20200907143300198.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvbmh1MTIzamF2YQ==,size_16,color_FFFFFF,t_70#pic_center)
可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W的数据,uudi的时间又直线下降。时间占用量总体可以打出的效率排名为:

auto_key>random_key>uuid,uuid的效率最低,在数据量较大的情况下,效率直线下滑。那么为什么会出现这样的现象呢?带着疑问,我们来探讨一下这个问题:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
https://gitee.com/Yrion/mysqlIdDemo

手把手教你用Chrome DevTools逆向分析抖音a_bogus参数(附完整日志插桩方法) 本文详细介绍了如何使用Chrome DevTools逆向分析抖音a_bogus参数的生成逻辑,包括XHR断点定位、日志插桩追踪和加密核心逻辑解析。通过实战案例,帮助开发者掌握逆向工程技巧,应对抖音接口的动态加密变化,特别适合研究dy接口和a_bogus参数的技术人员。 阅读详情

相关推荐

用Python实现图片风格迁移,让你的图片更加的高逼格!

先来看下效果: 上图是老王在甘南合作的米拉日巴佛阁外面拍下的一张照片,采用风格迁移技术后的效果为: 一些其它效果图: 下面进入正题。 近年来,由深度学习所引领的人工智能(AI)技术浪潮,开始越来越广泛地应用到生活各个领域。这其中,人工智能与艺术的交叉碰撞,在相关技术领域和艺术领域引起了高度关注。就在上个月,由电脑生成的艺术品在佳士得(Christie’s)的拍卖价竟高达43.25万美元,...

Python追梦 6184

【Mysql】雪花算法(Snowflake)

雪花算法(Snowflake)是一种生成全局唯一ID的分布式算法。它的主要功能是在分布式系统中生成一个全局唯一的ID,且ID是按照时间有序递增的。Snowflake 中文的意思为雪花,所以 Snowflake算法 常被称为 雪花算法,是 Twitter(现“X”)开源的分布式 ID 生成算法,是一种分布式主键ID生成的解决方案。生成后是一个 64bit 的 long 型的数值,组成部分引入了时间戳,基本保持了自增。互联网大厂实现的雪花开源项目: 二、核心思想 Snowflake算法使用一个64位的二进

精益求精 4531

游戏开发实战:5种AOI算法对比(九宫格 vs 灯塔 vs 十字链表)

本文深入对比了游戏开发中五种主流AOI算法(九宫格、灯塔、十字链表等)的性能与适用场景,帮助开发者根据项目规模选择最优解决方案。通过详细的技术分析和实战数据,揭示不同算法在万人同屏等极端场景下的表现差异,为MMORPG等大型多人在线游戏提供关键性能优化指南。

weixin_29268385的博客 476

MySQL DML语句中使用雪花ID

replace(unix_timestamp(current_timestamp(3)),‘.’,‘’): 去掉小数点,成为以毫秒为单位的时间戳;unix_timestamp(current_timestamp(3)): 得到当前时间对应的时间戳,小数点后面是毫秒;1420041600000: 初始时间;(雪花算法是时间差,具体可查阅雪花算法原理);current_timestamp(3): 当前时间,秒精度为3.左移22位: 留出10位的机器码和12位序列码;或运算: 随机序列码。

一点博客 1103

配置VS Code使用Linux服务器上的Matlab

0、需求 Linux服务器上安装有Matlab 无图形界面,只能使用命令行工具,编辑文件不方便 1、VS Code插件安装 在扩展商店中搜索matlab,会出现Matlab Extension Pack,里面有整理好的matlab扩展 这里只安装了第一排的三个扩展 2、设置(Windows、Mac的设置类似,只是不同系统的文件路径不同) 安装好扩展,重启VS Code后,进行设置 打开:文件→首选项→设置(或快捷键ctrl+,),搜索matlab,结果如下图所示;直接打开完整json配置文件(图

赵彬的博客 5011

FPGA设计中的扇出约束实战:从XDC到代码优化的全流程解析

本文全面解析FPGA设计中扇出约束的重要性与应用,详细介绍了从XDC约束文件设置到HDL代码优化的全流程实战技巧。通过MAX_FANOUT约束控制信号负载,结合寄存器复制和物理优化策略,有效解决高扇出导致的时序违例和布线拥塞问题,提升设计性能和可靠性。

nept的博客 798

Mysql 自增id、uuid与雪花id 以及 自增id和业务id如何抉择

自增iduuidUUID是UniversallyUniqueIdentifier的缩写,它是在一定的范围内(从特定的名字空间到全球)唯一的机器生成的标识符。通用唯一标识符的意思,可以以业务实际userid为主键比如QQ号手机号等雪花id相比UUID无序生成的id而言,雪花算法是有序的(有时间参数),而且都是由数字组成。雪花id最大为64位,符合java中long的长度64位。适用于大规模分布式。.........

S_ZaiJiangHu的博客 1万+

CentOS7 安装天气分型软件cost733过程详解

cost733是一款天气分型软件,其内置的一些算法可以帮助气象工作者进行天气类型划分等(我也是初学者,仅仅知道一些皮毛),但是网上找到的安装办法比较少,并且总会出现一些报错,试了一晚上,终于将安装办法调通了,希望可以帮助到大家

weixin_62573024的博客 3564

MySQL用SQL生成雪花ID

MySQL用SQL生成伪雪花ID

月上千秋河 2810

RV1106G3的AOV下的yolov5调试记录

本文介绍了基于LuckFoxPicoMax开发板的RV1106芯片调试经验,重点包括AOV(Always-On Vision)和Yolov5目标检测的实现。在硬件方面,板载1TOPS NPU、256MB内存,并更换为SPI NOR存储。软件调试涉及MK配置文件修改、设备树调整(按键唤醒和sensor配置)以及程序自启动设置。Yolov5模型优化为320*320尺寸,推理时间约45ms。系统采用VI采图与AI识别通过共享内存通信的方案,实测功耗在20-35mA范围。文章还指出了当前存在的功耗优化、ISP调试等

fzktongyong的博客 1715

OAI-5G开源通信平台实践(一)-安装 部署及RFsimulator基本测试

OAI (Open Air Interface) 是目前开源5G/4G项目中最完善、最成熟的一个,并且仍然在持续更新。其包含基站、终端及核心网网元的代码,可基于x86\arm+射频卡搭建实际硬件平台,也可在x86平台上对rf\phy等层进行模拟,做各网元协议栈的单独测试验证。本文总结了x86平台下,oai的安装及运行方式。包括NTN分支和主分支的rf simulator、nos1、端到端部署等场景的验证流程,同时总结了验证过程中遇到的问题及解决方法。

十年通信老兵的技术修炼之路——从3G到5G,从地面基站到卫星通信。 2969

MySQL 雪花Id函数

snowflake是Twitter开源的分布式ID生成算法,结果是64bit的Long类型的ID,有着全局唯一和有序递增的特点。最高位是符号位,因为生成的 ID 总是正数,始终为0,不可用。41位的时间序列,精确到毫秒级,41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。10位的机器标识,10位的长度最多支持部署1024个节点。

互联网民工手记 7245

SAP Gateway 故障排查全景图:从 Error Log 到 E2E 追踪,一套面向实战的工具与方法论

本文针对SAP Gateway Foundation(SAP_GWFND)的故障排查需求,梳理了从现象到根因的系统化排查路径。文章首先强调建立标准化排障流程的重要性,随后提供工具矩阵及使用顺序指引:对于请求中断优先查看Error Log(/IWFND/ERROR_LOG和/IWBEP/ERROR_LOG),性能问题使用Performance Trace(/IWFND/TRACES),通知异常则检查Notification Monitor。重点工具包括: Error Log作为中断类错误首要定位器; Appl

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 249

【MySQL】mysql中不推荐使用uuid或者雪花id作为主键的原因以及差异化对比

在数据库设计中,选择适当的主键类型对于数据的存储和查询效率至关重要。在MySQL中,有些开发者倾向于使用UUID(Universally Unique Identifier)或者雪花ID作为主键,以确保数据的唯一性。然而,这种做法并不总是推荐的,因为它们在性能、存储空间和索引效率等方面存在一些问题。本文将探讨在MySQL中不推荐使用UUID或者雪花ID作为主键的原因,并与其他主键类型进行差异化对比。

Venus's Blog 1万+

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

深入分析mysql为什么不推荐使用uuid或者雪花id作为主键

在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?本篇博客我们就来分析这个问题,探讨一下内部的原因。 一:mysql和程序实例 1.1:准备数据 要说明这个问题,我们首先来建立三张表,分别是 user_auto_key ,user_uuid,user_random_key,分别表示自动增长的主键, uuid作为主键,.

LoveSummer 3987

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

为什么?mysql不推荐使用uuid或者雪花id作为主键?

前言: 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?本篇博客我们就来分析这个问题,探讨一下内部的原因。 一:mysql和程序实例 1.1:要说明这个问题,我们首先来建立三张表,分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为

Venus's Blog 3万+

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

【MySQL】为什么不推荐使用uuid或者雪花id作为主键?

①:写入的目标页很可能已经刷新到磁盘上并且从缓存上移除,或者还没有被加载到缓存中,innodb在插入之前不得不先找到并从磁盘读取目标页到内存中,这将。因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb。使用UUID或雪花ID(Snowflake ID)作为主键并不是完全不推荐的,而是。①下一条记录就会写入新的页中,一旦数据按照这种顺序的方式加载,主键页就会。这个过程需要做很多额外的操作,数据的毫无顺序会导致数据。②新插入的行一定会在原有的。

weixin_45618869的博客 1755

为什么MySQL不推荐使用uuid或者雪花id作为主键

当数据量庞大时,UUID会显著增加存储空间占用,尤其是在有多个二级索引的情况下(每个二级索引都会存储主键值)。:虽然趋势递增,但在分布式系统中,不同节点生成的ID可能存在时间戳差异,导致局部无序,仍可能引发页分裂。若主键较大(如UUID),所有二级索引的叶子节点都会存储主键值,导致索引体积膨胀,进一步影响查询性能。:完全随机的主键值会导致新数据插入到索引中间,频繁触发页分裂和重组,增加I/O开销,降低写入性能。:在分布式系统中,雪花ID是较好的折中选择,但需确保时钟同步,并评估局部无序对插入性能的影响。

qq_34548728的博客 754
上一篇: 行列转换
下一篇: 加密算法
yonhu123java
博客等级 码龄14年 6粉丝 47原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值