首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

mysql设置主键为uuid

基础概念

MySQL中的主键(Primary Key)是用于唯一标识表中每一行数据的字段。主键必须满足以下条件:

  1. 唯一性:每个值必须是唯一的。
  2. 非空性:值不能为空。

UUID(Universally Unique Identifier)是一种由 128 位数构成的标识符,通常用于确保数据库表中的记录具有全局唯一性。

优势

  1. 全局唯一性:UUID可以确保在不同的数据库实例、不同的服务器、甚至不同的数据中心之间都能保持唯一性。
  2. 安全性:UUID不容易被猜测,因此在某些安全敏感的应用中,使用UUID作为主键可以提高安全性。
  3. 扩展性:UUID可以避免传统自增主键可能导致的性能瓶颈和扩展性问题。

类型

MySQL中支持多种数据类型来存储UUID,常见的有:

  • CHAR(36):存储标准的36字符长度的UUID字符串。
  • BINARY(16):存储16字节的二进制UUID。
  • VARCHAR(36):存储36字符长度的UUID字符串,但通常不推荐使用,因为性能不如CHAR(36)

应用场景

  1. 分布式系统:在分布式系统中,UUID可以确保不同节点生成的ID是唯一的。
  2. 高并发系统:在高并发系统中,UUID可以避免自增主键可能导致的性能瓶颈。
  3. 安全敏感的应用:在需要防止ID被猜测的应用中,UUID可以提供更好的安全性。

设置主键为UUID的示例

假设我们有一个名为users的表,我们将主键设置为UUID类型:

代码语言:txt
复制
CREATE TABLE users (
    id CHAR(36) PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL UNIQUE
);

生成UUID的示例

在插入数据时,可以使用MySQL内置的UUID()函数生成UUID:

代码语言:txt
复制
INSERT INTO users (id, name, email) VALUES (UUID(), 'John Doe', 'john.doe@example.com');

遇到的问题及解决方法

问题1:UUID作为主键的性能问题

原因:UUID是无序的,插入数据时会导致索引页的分裂,从而影响性能。

解决方法

  1. 使用有序的UUID:可以使用类似Twitter的Snowflake算法生成的ID,这些ID是有序的,可以减少索引页的分裂。
  2. 使用BINARY(16)类型:存储UUID的二进制形式,可以提高存储和查询效率。
代码语言:txt
复制
CREATE TABLE users (
    id BINARY(16) PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL UNIQUE
);
  1. 分区表:对于非常大的表,可以考虑使用分区表来分散数据,减少单个索引页的压力。

问题2:UUID字符串长度问题

原因:UUID字符串长度为36个字符,可能会影响查询性能和存储空间。

解决方法

  1. 使用BINARY(16)类型:存储UUID的二进制形式,可以节省存储空间并提高查询效率。
  2. 使用CHAR(36)类型:虽然字符串长度较长,但可以保证数据的可读性。

参考链接

希望这些信息对你有所帮助!如果有更多问题,请随时提问。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

为啥不能用uuid做MySQL的主键 ?

在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,...本篇博客的目录 mysql程序实例 使用uuid和自增id的索引结构对比 总结 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid...,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变....,提升了页面的最大填充率,不会有页的浪费 ②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 ③减少了页分裂和碎片的产生 2.2.使用uuid的索引内部结构...在实际的开发中还是根据mysql的官方推荐最好使用自增id,mysql博大精深,内部还有很多值得优化的点需要我们学习。

3.9K20

java中使用uuid函数_uuid主键

由以下几部分的组合:当前日期和时间(UUID的第一个部分与时间有关,如果你在生成一个UUID之后,过几秒又生成一个UUID,则第一个部分不同,其余相同),时钟序列,全局唯一的IEEE机器识别号(如果有网卡...UUID作用: 我们通常使用int来做数据库的主键,可以很方便的使用自增长,但是使用int数据范围有限制。如果存在大量的数据,可能会超出int的取值范围。所以我们可以使用uuid来做主键。...java.Util.UUID,用于方便生成UUID。...createUUID(){ String uuid=UUID.randomUUID().toString();return uuid.replace(“-“,””); } } 运行: 数据库中UUID...的存储类型 以mySql数据库为例 select replace(uuid(),’-‘,”) from dual; 运行: 版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。

2.5K30
  • 为什么MySQL不推荐使用uuid作为主键?

    前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用...关于MySQL的知识点总结了一个思维导图分享给大家 [1240] 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key...,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变....表写入结果: [1240] 1.4.效率测试结果 [1240] 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: [1240] 可以看出在数据量100W左右的时候,uuid...,提升了页面的最大填充率,不会有页的浪费 ②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 ③减少了页分裂和碎片的产生 2.2.使用uuid的索引内部结构

    5.1K30

    使用uuid做MySQL主键,被老板,爆怼一顿!

    来源:cnblogs.com/wyq178/p/12548864.html 前言:在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键...一:mysql和程序实例 1.1:要说明这个问题,我们首先来建立三张表,分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...表写入结果: 1.4:效率测试结果 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: 可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W...,提升了页面的最大填充率,不会有页的浪费 ②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 ③减少了页分裂和碎片的产生 2.2:使用uuid的索引内部结构...在实际的开发中还是根据mysql的官方推荐最好使用自增id,mysql博大精深,内部还有很多值得优化的点需要我们学习。

    1.2K30

    使用uuid做MySQL主键,被老板,爆怼一顿!

    和自增id的索引结构对比 2.1.使用自增id的内部结构 2.2.使用uuid的索引内部结构 2.3.使用自增id的缺点 三、总结 ---- 前言 在mysql中设计表的时候,mysql官方推荐不要使用...uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?...本篇博客的目录 mysql程序实例 使用uuid和自增id的索引结构对比 总结 基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序...,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变....表写入结果: 1.4.效率测试结果 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: 可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W

    1.7K60

    mysql 设置主键命令_MySQL常用命令

    1、修改MySQL密码 方法一: use mysql; update user set password=PASSWORD(“123456”) where user=‘root’; flush privileges...那么password字段要改成authentication_string 创建数据库用户: 单纯的创建:create user ‘name’@‘host’ identified by ‘密码’ 创建时设置用户权限...数据库名称; 3、创建表以及删除表 create table 表名称(表中字段名称 类型); 创建:create table test(id int(10) not null) #int表示id字段为值为整型...,且长度为10,不允许该字段为空 删除:drop table 表名称 drop table test 4、表中插入数据 insert into test(id) values(1002); #此处注意如果字段值设置为...方式一: 创建表时创建主键:create table test(id int(10),name char(20),primary key id); 方式二: 创建完表之后添加主键:alter table

    3.8K20

    MySQL中主键为0和主键自排约束的关系

    开始不设置主键 表的设计如下: 如果id的位置有好几个0的话:设置主键并且自动排序时,0会从1开始递增; Insert 进去 id = 0的数据,数据会从实际的行数开始增加,和从0变化不一样;...如果使用主键自排约束以前表里有0,再设置完主键自排以后所有的0又不会根据行数,而是直接按照自上而下的顺序从1开始排。...如果把表中的某个主键的数改成0,那直接就会进行排序放到正数前面,也就是说主键自排是允许有0存在的,那为什么本身存在的0要去修改成从1开始的递增序列呢?...哪怕没加主键自排以前只有一个0,加了主键自排以后还是会变成1。   开始有0,增加主键自排约束,0依次变为1,2,3,4.......   ...开始没0,增加主键自排约束,新添加的主键是0的行会根据行数自行变化,注意这里是新添加的行,使用的是insert。   开始没0,把某个主键的数修改成0,这个0会直接在排好序了再在表里显示出来。

    4.3K30

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

    p=5090 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment...一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...用户uuid表 ? 随机主键表: ?...user_uuid表写入结果: ? 1.4.效率测试结果 ? 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: ?...,提升了页面的最大填充率,不会有页的浪费 ②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 ③减少了页分裂和碎片的产生 2.2.使用uuid的索引内部结构

    4K20

    mysql 自增id和UUID做主键性能分析,及最优方案

    UUID UUID 是 通用唯一识别码(Universally Unique Identifier)的缩写,是一种软件建构的标准,亦为开放软件基金会组织在分布式计算环境领域的一部分。...在ColdFusion中可以用CreateUUID()函数很简单地生成UUID,其格式为:xxxxxxxx-xxxx- xxxx-xxxxxxxxxxxxxxxx(8-4-4-16),其中每个 x 是...而标准的UUID格式为:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12),可以从cflib 下载CreateGUID() UDF进行转换。...(2).对于InnoDB的主索引,数据会按照主键进行排序,由于UUID的无序性,InnoDB会产生巨大的IO压力,此时不适合使用UUID做物理主键,可以把它作为逻辑主键,物理主键依然使用自增ID。...4.如果非要使用uuid做主键,下面是小建议: 如果是主从即M-S模式,最好是不使用mysql自带函数uuid来生成唯一主键,因为主表生成的uuid要再关联从表时,需要再去数据库查出这个uuid,需要多进行一次数据库交互

    8.4K20

    华为面试官:为什么MySQL不推荐使用uuid作为主键?

    1、前言 在MySQL中设计表的时候,MySQL官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用...2 MySQL和程序实例 ★ 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key...表写入结果: ★ 效率测试结果 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: 可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W...,提升了页面的最大填充率,不会有页的浪费 新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 减少了页分裂和碎片的产生 ★ 使用uuid的索引内部结构...,主键的上界会成为争抢的热点,因为所有的插入都发生在这里,并发插入会导致间隙锁竞争 Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失 4 最后 在实际的开发中还是根据MySQL的官方推荐最好使用自增

    2.1K20

    mysql 联合主键_Mysql 创建联合主键

    Mysql 创建联合主键 2008年01月11日 星期五 下午 5:21 使用primary key (fieldlist) 比如: create table mytable ( aa int, bb...char(8), cc date, primary key (aa,bb ) ); aa,bb为联合主键 不知道是不是因为mysql(6.0)的版本问题,还是各版本都是这种情况,mysql中创建联合主键...TABLE t1( id … MySQL创建双主键 如下: CREATE TABLE `loginlog` ( `id` ) unsigned zerofill NOT NULL AUTO_INCREMENT...COMMENT ‘主键编号’, `IP` … mysql修改联合主键 参考 https://blog.csdn.net/BockSong/article/details/80933477 alter...涉及的知识点总结如下: One to One 映射关系 一对一单向外键(XML/Annotation) 一对一双向外键关联(XML/A … SQL Server中的联合主键、聚集索引、非聚集索引、mysql

    8.3K20

    使用雪花id或uuid作为MySQL主键,被老板怼了一顿!

    磊哥,前几天在做项目demo的时候,使用雪花id或uuid作为Mysql主键,被老板怼了一顿!...一、MySQL和程序实例 1.1 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...用户uuid表 ? 随机主键表: ?...user_uuid表写入结果: ? 1.4 效率测试结果 ? 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: ?...,提升了页面的最大填充率,不会有页的浪费 ②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 ③减少了页分裂和碎片的产生 2.2 使用uuid的索引内部结构

    8.9K32

    使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    来源:cnblogs.com/wyq178/p/12548864.html ---- 前言:在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一)...,而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?...一、mysql和程序实例 1.1 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...表写入结果: 1.4 效率测试结果 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: 可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W...减少了页分裂和碎片的产生 2.2 使用uuid的索引内部结构 因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后

    1.2K20

    使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    ---- 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment...本篇博客的目录 mysql程序实例 使用uuid和自增id的索引结构对比 总结 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid...,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变....用户uuid表 ? 随机主键表: ?...user_uuid表写入结果: ? 1.4.效率测试结果 ? 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: ?

    2.2K10

    使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    前言: 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用...# mysql和程序实例 1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key...表写入结果: 4.效率测试结果 在已有数据量为130W的时候:我们再来测试一下插入10w数据,看看会有什么结果: 可以看出在数据量100W左右的时候,uuid的插入效率垫底,并且在后序增加了130W...,提升了页面的最大填充率,不会有页的浪费 新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快,不会为计算新行的位置而做出额外的消耗 减少了页分裂和碎片的产生 2.使用uuid的索引内部结构...在实际的开发中还是根据mysql的官方推荐最好使用自增id,mysql博大精深,内部还有很多值得优化的点需要我们学习。

    1.6K10

    使用雪花 id 或 uuid 作为 MySQL 主键,被老板怼了一顿!

    和程序实例 **1.1 要说明这个问题, 我们首先来建立三张表** 分别是`user_auto_key,user_uuid`,`user_random_key`, 分别表示自动增长的主键, uuid...作为主键, 随机 key 作为主键, 其它我们完全保持不变....juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8d91f0b758e14dd9bac0fa893f173524~tplv-k3u1fbpfcp-zoom-1.image) 在已有数据量为...写入的目标页很可能已经刷新到磁盘上并且从缓存上移除,或者还没有被加载到缓存中,innodb 在插入之前不得不先找到并从磁盘读取目标页到内存中,这将导致大量的随机 IO ②:因为写入是乱序的, innodb 不得不频繁的做页分裂操作, 以便为新的行分配空间...在实际的开发中还是根据 mysql 的官方推荐最好使用自增 id,mysql 博大精深,内部还有很多值得优化的点需要我们学习。

    2.9K00
    领券