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

mysql雪花算法生成唯一整型ID主键的实现方法 mysql雪花算法生成唯一整型ID主键的实现方法,整型ID作为主键好处有很多,比如节省存储空间、插入和查询排序快、具有一定规律性(时间顺序)等。 立即下载

点击上方“芋道源码”,选择“设为星标”

管她前浪,还是后浪?

能浪的浪,才是好浪!

每天 8:55 更新文章,每天掉亿点点头发...

源码精品专栏

 

来源:cnblogs.com/wyq178/p/12548864.html

  • 前言

  • 一、mysql和程序实例

    • 1.1.要说明这个问题,我们首先来建立三张表

    • 1.2.光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试:

    • 1.3.程序写入结果

    • 1.4.效率测试结果

  • 二、使用uuid和自增id的索引结构对比

    • 2.1.使用自增id的内部结构

    • 2.2.使用uuid的索引内部结构

    • 2.3.使用自增id的缺点

  • 三、总结


前言

在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?

本篇博客我们就来分析这个问题,探讨一下内部的原因。

一、mysql和程序实例

1.1.要说明这个问题,我们首先来建立三张表

分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变.

根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样,然后测试一下表的插入速度和查询速度:

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

id自动生成表:

用户uuid表

随机主键表:

1.2.光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试:

技术框架:springboot+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);
    }

1.3.程序写入结果

user_key_auto写入结果:

user_random_key写入结果:

user_uuid表写入结果:

1.4.效率测试结果

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

可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W的数据,uudi的时间又直线下降。

时间占用量总体可以打出的效率排名为:auto_key>random_key>uuid,uuid的效率最低,在数据量较大的情况下,效率直线下滑。那么为什么会出现这样的现象呢?带着疑问,我们来探讨一下这个问题:

二、使用uuid和自增id的索引结构对比

2.1.使用自增id的内部结构

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

①下一条记录就会写入新的页中,一旦数据按照这种顺序的方式加载,主键页就会近乎于顺序的记录填满,提升了页面的最大填充率,不会有页的浪费

②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗

③减少了页分裂和碎片的产生

2.2.使用uuid的索引内部结构

因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间。

这个过程需要做很多额外的操作,数据的毫无顺序会导致数据分布散乱,将会导致以下的问题:

①写入的目标页很可能已经刷新到磁盘上并且从缓存上移除,或者还没有被加载到缓存中,innodb在插入之前不得不先找到并从磁盘读取目标页到内存中,这将导致大量的随机IO

②因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据,一次插入最少需要修改三个页以上

③由于频繁的页分裂,页会变得稀疏并被不规则的填充,最终会导致数据会有碎片

在把随机值(uuid和雪花id)载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充,这将又需要一定的时间消耗。

结论:使用innodb应该尽可能的按主键的自增顺序插入,并且尽可能使用单调的增加的聚簇键的值来插入新行

2.3.使用自增id的缺点

那么使用自增的id就完全没有坏处了吗?并不是,自增id也会存在以下几点问题:

①别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息,很容易分析出你的经营情况

②对于高并发的负载,innodb在按主键进行插入的时候会造成明显的锁争用,主键的上界会成为争抢的热点,因为所有的插入都发生在这里,并发插入会导致间隙锁竞争

③Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

附:Auto_increment的锁争抢问题,如果要改善需要调优innodb_autoinc_lock_mode的配置

三、总结

本篇博客首先从开篇的提出问题,建表到使用jdbcTemplate去测试不同id的生成策略在大数据量的数据插入表现,然后分析了id的机制不同在mysql的索引结构以及优缺点,深入的解释了为何uuid和随机不重复id在数据插入中的性能损耗,详细的解释了这个问题。

在实际的开发中还是根据mysql的官方推荐最好使用自增id,mysql博大精深,内部还有很多值得优化的点需要我们学习。



欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢:

已在知识星球更新源码解析如下:

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 20 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。

获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。

兄弟,艿一口,点个赞!????

告别连接难题:Windows 11下Multisim主数据库稳定运行终极配置指南 本文详细解析了Windows 11下Multisim 14.0主数据库连接失败的三大根源,并提供了四步终极解决方案,包括系统环境优化、软件权限配置、注册表修复和网络验证绕过技巧。通过实测数据对比,本方案显著提升了启动速度和稳定性,解决了电子仿真中的常见连接问题。 阅读详情

相关推荐

智能车视觉算法实战:十字路口与弯道拐点的精准识别

本文深入探讨了智能车视觉导航中十字路口与弯道拐点的精准识别算法。通过实战经验,详细解析了如何利用纵向巡线法生成边界数组,并从中高效提取“上拐点”与“下拐点”的关键特征。文章重点分享了提升算法鲁棒性的核心技巧,包括图像预处理、ROI设置、状态机应用及多特征融合,旨在帮助开发者实现智能车在复杂路况下从“看见”到“看懂”的稳定决策。

weixin_29061465的博客 633

【Mysql】雪花算法(Snowflake)

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

精益求精 4531

AI编程实战:用Spec Coding与Codex半小时重构全栈项目

这次我们来看一个能显著提升全栈开发效率的实战方法:利用 AI 编程工具 Codex 和 Spec Coding 工作流,将原本需要数周甚至一个月的全栈项目重构工期,压缩到半小时级别。这不是概念探讨,而是基于现有工具链的、可立即上手的工程实践。 对于前端开发者或全栈工程师而言,面对老旧项目重构、技术栈升级或从零搭建新项目时,最大的痛点往往是重复性、模式化的代码编写工作。手动编写 CRUD 接口、页面组件、状态管理和联调测试,耗时费力且容易出错。而 AI 辅助编程的核心价值,正是在于将开发者从这些“体力活”中解

weixin_33525298的博客 290

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

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

S_ZaiJiangHu的博客 1万+

Spring Boot应用Docker化实战:从Dockerfile编写到镜像推送完整流程

本文详细介绍了将Spring Boot应用Docker化的完整实战流程。从环境准备、项目审视,到编写高效且安全的Dockerfile,重点讲解了多阶段构建、镜像层优化、Spring Boot分层JAR等核心技巧,并涵盖了镜像构建、验证、调试以及最终推送至仓库并集成CI/CD的最佳实践,帮助开发者构建生产级Docker镜像。

butter的博客 1023

超越音频!STM32 SAI接口在AD7768高速ADC采集中的妙用(含PCB布局指南)

本文深入探讨了如何将STM32的SAI接口应用于AD7768高速ADC的数据采集系统,超越了其传统的音频应用范畴。文章详细解析了SAI协议与ADC时序的匹配方法,提供了从CubeMX配置、DMA数据搬运到关键PCB布局指南的完整实战方案,旨在帮助工程师实现稳定、高精度的工业级高速数据采集。

efc12345678的博客 305

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

点击上方蓝色字体,选择“标星公众号”优质文章,第一时间送达关注公众号后台回复pay或mall获取实战项目资料视频 点击此链接:一套SpringCloud电商项目,拿来即用(附详细教程和文...

公众号-老炮说Java 1130

永磁同步电机无传感器控制:HFI与ESMO技术详解

高频注入(HFI)和增强型滑模观测器(ESMO)是现代永磁同步电机(PMSM)无传感器控制的核心技术。HFI通过注入高频信号利用电机凸极效应获取转子位置,而ESMO则通过改进传统滑模观测器,有效抑制抖振并提升动态响应。这两种技术的结合特别适用于零低速区域的位置估计,在工业伺服、电动汽车等领域有广泛应用。方波高频注入作为实现方案之一,具有计算量小、实现简单的特点,配合自适应滤波等信号处理技术,可以在保证精度的同时降低系统成本。

weixin_29183637的博客 357

MySQL 雪花Id函数

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

互联网民工手记 7245

别再踩坑了!QT5.15.2配置Android开发环境保姆级避坑指南(含Java8、SDK Tools版本选择)

本文提供QT5.15.2配置Android开发环境的详细避坑指南,重点解决版本锁定、SDK工具选择和QtCreator配置等常见问题。通过实测推荐的Java8、Android SDK Tools版本及NDK配置,帮助开发者高效完成环境搭建,避免隐性冲突和配置失败。

weixin_42537919的博客 240

CP AUTOSAR标准之AUTOSAR OS(AUTOSAR_SWS_OS)(二)

AUTOSAR OS是一个Operating System,即操作系统。它最核心的功能是管理任务和事件的调度,不同任务间的同步流,并且提供监控和错误处理功能。或者用最简化理解就是一个函数调度器。

CoolBreeze的博客 654

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

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

Venus's Blog 1万+

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 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作为主键,.

LoveSummer 3987

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

为什么?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万+

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

【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
上一篇: 深入研究 System.out.println()
下一篇: 天啊,为什么我的 Redis 变慢了。。
公众号-芋道源码
博客等级 码龄10年 1634粉丝 377原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值