在MySQL中, 自增主键和UUID作为主键有什么区别?

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 自增主键和UUID在MySQL中各有优缺点,选择哪种方式作为主键取决于具体的应用场景和需求。例如,在需要高性能插入和查询的场景下,自增主键可能更合适;而在需要保证主键全局唯一性和不可预测性的场景下,UUID可能更合适。

首先我们来看看, 存储自增主键和uuid的数据类型

        mysql中作为主键的通常是int类型的数据, 这个 数据从第一条记录开始, 从1开始主键往后递增, 例如我有100条数据, 那么根据主键排序后, 里面的记录从上往下一次就是1, 2, 3 ... 100, 但是UUID就不一样了, UUID是根据特殊的算法, 来生成唯一的一个字符串, 他的长度高达128个比特位, 而标准的UUID格式为:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12), 每一个x都是 0-9 或 a-f 范围内的一个十六进制的数字, 因此他需要使用字符串格式来进行存储, 标准的uuid的长度是32个字符, 外加两个短线, 也就是34个字符

       在mysql中对int类型值的处理速度是比字符串的速度要快的, 因此在速度上, 是肯定比不过自增主键的, 我们在比较UUID, 然后对这些UUID进行一个排序的, 是一个字符一个字符的进行比较的, 例如有两个UUID, 那么就是从第一个字符比较, 如果第一个字符相等, 就比较下一个字符的大小, 以此类推, 直到比较完了, 那么两个字符串就想等, 如果存在字符的大小区别, 那么就根据不同的这个字符进行排序, 以此类推.

       所以你是用UUID进行存储, 那么相比于自增的主键, 那么你就要花费额外的空间来存储这些UUID, 在插入主键或者是uuid的时候, 会有一个插入顺序的问题, 对于主键, 如果你不指定主键的值, 然后给这个主键设置自增值, 那么在插入的时候, 就会按照最大主键值的下一位插入, 这个时候就会性能很高, 为什么这么说呢?  

       因为mysql底层是一个数据页为一个基本的读写单元, 一个数据页可以存放16kb的数据, 你可以理解为数据页里面的记录是一个链表, 假如此时你不是按主键自增的顺序插入, 并且你插入的主键对应的数据页刚好满了装不下了, 此时的话, 你就需要将一个页拆分为两页, 这个就造成了不必要的性能消耗. 如果你按照自增的形式插入, 那么他们就会以此在最后一个数据页里面插入, 如果不够了, 就创建新的数据页, 而不是将一个页差分为两个, 然后拷贝数据.    

        但是如果你是使用的UUID作为主键, 那么就没有这个功能, 你的字符串id是有序的, 但是你不能保证, 你下一个生成的uuid, 就一定是最大的, 因此被分页的可能性就会很高. 同时每一个主键的占用的空间大了, 那么一个数据页装的数据记录也会变少, 页面增多, 所以在对这些记录进行操作, 将数据页读取到内存中的时候, 读取的页数页随之增多. io成本随之增多.

       在存储和性能方面, 还是自增主键更胜一筹.

说了这么多仿佛都是UUID的缺点, 那UUID做主键就么没有有点吗?

       有点肯定是有的 , 例如UUID的长度很长, 并且是随机生成的, 他的主键的复杂性很高, 并且没有规律, 你不能够通过数据分析来预测下一个主键id是多少,这种不可预测性对于需要保密性的应用场景较为适用。

       还有另外一种场景, 假如现在有这样一个需求, 我需要将一个自增主键的表, 导入另外一个和当前表结构相同的表, 但是这个表已经存了很多数据, 这个时候我将其插入, 就会导入失败, 因为两个表前面几部分的id是重合的, 因此会插入失败. 同样的当你去拆分数据库的时候, 也可以很好的拆分, 并且避免id的重复导致数据的错乱.

       此时如果你使用的是UUID, 那么就可以避免这个问题.

总结:  

在MySQL中,使用自增主键(AUTO_INCREMENT)和UUID作为主键的主要区别体现在以下几个方面:

唯一性:

自增主键:确保主键的唯一性,每次插入新行时,数据库会自动为主键生成一个唯一的、比之前插入的最大主键值大1的整数值。

UUID:具有极高的唯一性,基于一定算法(如随机数生成器或时间戳)生成,几乎不可能重复。UUID由32位16进制数表示,共128位(标准的UUID格式为:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)。

数据类型和存储:

自增主键:只适用于整数类型的主键列(如INT、BIGINT等),存储空间相对较小。

UUID:虽然也是字符串类型,但由于其长度较长(32个字符),存储空间相对较大。

插入性能:

自增主键:在插入新行时,数据库可以很容易地将新行插入到索引的末尾,减少了页分裂或移动数据的频率,从而提高了插入性能。

UUID:由于UUID是随机生成的,插入时位置具有不确定性,可能导致无序插入和内存碎片,插入性能相对较差。

索引和查询性能:

自增主键:由于其递增的特性,非常适合用作聚集索引(Clustered Index),能够优化查询性能。同时,较小的索引大小也可以减少内存消耗,更好地适应于内存缓存。

UUID:由于UUID的无序性,可能导致索引碎片化,影响查询性能。同时,较大的索引大小也可能增加内存消耗。

可预测性:

自增主键:主键值是可预测的,因为它们是按顺序生成的。

UUID:主键值是不可预测的,因为它们是随机生成的。这种不可预测性对于需要保密性的应用场景较为适用。

删除和重新插入:

自增主键:在删除并重新插入数据后,可能会出现主键值“跳跃”的现象,即新插入的主键值可能会比之前删除的主键值大很多。

UUID:UUID在删除和重新插入数据时,主键值不会受到影响,因为它们是随机生成的。

        自增主键和UUID在MySQL中各有优缺点,选择哪种方式作为主键取决于具体的应用场景和需求。例如,在需要高性能插入和查询的场景下,自增主键可能更合适;而在需要保证主键全局唯一性和不可预测性的场景下,UUID可能更合适。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
27天前
|
存储 关系型数据库 MySQL
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB区别,适用场景
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景比较
|
20小时前
|
NoSQL 关系型数据库 MySQL
2024Mysql And Redis基础与进阶操作系列(4-2)作者——LJS[含MySQL非空、唯一性、PRIMARY KEY、自增列/自增约束举例说明等详解步骤及常见报错问题对应的解决方法]
24MySQL非空、唯一性、PRIMARY KEY、自增列/自增约束举例说明等详解步骤及常见报错问题对应的解决方法(4-2) 学不会你来砍我!!!
|
2天前
|
SQL 关系型数据库 MySQL
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
6 0
|
25天前
|
存储 SQL 关系型数据库
mysql中主键索引和联合索引的原理与区别
本文详细介绍了MySQL中的主键索引和联合索引原理及其区别。主键索引按主键值排序,叶节点仅存储数据区,而索引页则存储索引和指向数据域的指针。联合索引由多个字段组成,遵循最左前缀原则,可提高查询效率。文章还探讨了索引扫描原理、索引失效情况及设计原则,并对比了InnoDB与MyISAM存储引擎中聚簇索引和非聚簇索引的特点。对于优化MySQL性能具有参考价值。
|
25天前
|
SQL 关系型数据库 MySQL
MySQL设置表自增步长
MySQL设置表自增步长
42 0
|
26天前
|
存储 JSON 关系型数据库
MySQL 5.x和MySQL 8.x到底有什么区别?
本文详细对比了MySQL 5.x与MySQL 8.x的主要区别,包括存储引擎改进、性能提升、SQL语法增强(如窗口函数、CTE、JSON支持)、安全性和权限管理、并发及锁机制、InnoDB引擎增强、复制与高可用性等方面的显著差异。通过具体示例展示了8.x版本在企业级应用和高并发场景下的优越表现,建议有条件时尽早升级至MySQL 8.x以充分利用其新特性。
|
27天前
|
存储 关系型数据库 MySQL
Mysql行格式DYNAMIC和COMPACT区别
总之,选择哪种行格式取决于具体的应用场景,如数据类型分布、读写比例、存储与性能需求等。在处理大量文本或二进制数据且对存储空间敏感的应用中,DYNAMIC格式可能是更好的选择;而对于混合型数据且对读取性能有一定要求的场景,COMPACT格式可能更合适。在设计数据库时,评估这些因素并进行适当测试,可以帮助确定最适合的行格式。
62 0
|
18天前
|
存储 SQL 关系型数据库
Mysql学习笔记(二):数据库命令行代码总结
这篇文章是关于MySQL数据库命令行操作的总结,包括登录、退出、查看时间与版本、数据库和数据表的基本操作(如创建、删除、查看)、数据的增删改查等。它还涉及了如何通过SQL语句进行条件查询、模糊查询、范围查询和限制查询,以及如何进行表结构的修改。这些内容对于初学者来说非常实用,是学习MySQL数据库管理的基础。
78 6
|
16天前
|
存储 关系型数据库 MySQL
Mysql(4)—数据库索引
数据库索引是用于提高数据检索效率的数据结构,类似于书籍中的索引。它允许用户快速找到数据,而无需扫描整个表。MySQL中的索引可以显著提升查询速度,使数据库操作更加高效。索引的发展经历了从无索引、简单索引到B-树、哈希索引、位图索引、全文索引等多个阶段。
50 3
Mysql(4)—数据库索引
|
1天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
14 2