Mysql 使用UUID 作为主键的分析

前置条件
Mysql innodb存储引擎

一:为什么使用UUID

UUID 是 通用唯一识别码(Universally Unique Identifier)的缩写,是一种软件建构的标准,亦为开放软件基金会组织在分布式计算环境领域的一部分。其目的,是让分布式系统中的所有元素,都能有唯一的辨识信息,而不需要通过中央控制端来做辨识信息的指定。如此一来,每个人都可以创建不与其它人冲突的UUID。
UUID 便于生成,不会重复,在分布式架构的系统中,很常见,但对于使用了mysql innodb 存储引擎来说,UUID 则不是一个好的选择。

二、UUID做主键的缺点分析

2.1 UUID 比较长 占用空间

默认32位的char,作为主键的时候更加占用表的空间,业务中需要实体的关系、连表查询,导致表空间被UUID字段所占用,不利用后期的数据库优化。

2.2UUID 没有顺序,随机生成

innodb 中默认是主键 B+树索引的,UUID 生成没有顺序,所以insert操作是随机的,数据被离散存储,造成innodb频繁的页分裂,使得insert的操作十分低效。

innodb 的表存储是有顺序的,UUID的生成没有顺序。

2.3 影响二级索引

innodb 的非主键索引受影响,我们知道 主键索引叶子节点存储的是
数据data,而二级索引(非主键索引)叶子节点存储的是主键id,这样一来,表中的二级索引要存储UUID ,占用空间。

2.4uuid之间比较大小相对数字慢不少, 影响查询速度。

这点有待考证,如果是主键索引那么理论上已经有了顺序,若是数字比较 大小快于字符串比较大小是有可能的。

参考资料:https://rdcqii.hundsun.com/portal/article/953.html

三、雪花算法

mybatisplus内置雪花算法。

详情:
https://www.jianshu.com/p/2a27fbd9e71a

### 在 MySQL 中同时使用 UUID 和 自增主键的方法 #### 方法概述 为了充分利用两种主键的优势,在实际应用中可以选择创建两个字段分别用于存储自增 ID 和 UUID。通常情况下,自增 ID 被设为主键并负责唯一标识记录;而 UUID 则作为一个辅助列存在,主要用于跨系统识别或分布式环境下的数据同步。 #### 实现方式 可以通过定义复合主键的方式来实现这一目标: ```sql CREATE TABLE example_table ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, uuid CHAR(36) NOT NULL DEFAULT (UUID()), name VARCHAR(255), PRIMARY KEY (id), -- 设置自增ID为主键 UNIQUE INDEX idx_uuid(uuid)-- 添加唯一索引到UUID上以确保其唯一性 ); ``` 上述 SQL 语句展示了如何在一个表内同时维护 `id`(自增整数型)和 `uuid` 字段,并通过设置合适的约束条件来保障两者的特性和功能[^1]。 #### 注意事项 当采用这种方式时需要注意以下几点: - **性能影响**:虽然引入了额外的 UUID 字段,但由于查询操作主要依赖于效率更高的自增主键,因此整体性能不会受到太大负面影响。 - **空间占用**:相比单纯的自增主键方案,此方法确实增加了每条记录所需存储的空间量,因为需要保存较长字符串形式的 UUID 值。 - **插入顺序问题**:由于自增主键能够保证新纪录总是追加到最后位置,这有助于提高写入速度;而对于随机生成UUID,则可能引起页分裂等问题从而降低性能[^2]. #### 优点对比 | 特征 | 自增主键 | UUID | | --- | --- | --- | | 数据长度 | 较短 | 较长 | | 插入性能 | 更高 | 可能较低 | | 分布式支持 | 不友好 | 支持 | 综上所述,在某些特定场景下,比如涉及到多数据库实例间的数据交换或是希望获得全局唯一的实体标识符的情况下,可以考虑这种混合模式的设计思路[^3]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值