跳转到主要内容

为什么 UUID v7 更适合做数据库主键?

Avatar emanjusaka
统计中…
240
0
为什么 UUID v7 更适合做数据库主键?

by emanjusaka from https://www.emanjusaka.com/archives/uuid-v7 彼岸花开可奈何

本文为原创文章,可能会更新知识点以及修正文中的一些错误,全文转载请保留原文地址,避免产生因未即时修正导致的误导。

博客:https://www.emanjusaka.com

博客园:https://www.cnblogs.com/emanjusaka

公众号:毅念安

UUID v7 是基于时间戳的新型全局唯一标识符,具有时间有序性和分布式友好特性,适用于需要索引优化的数据库场景和分布式系统。

UUID 的基础结构和版本 1-5 差异,可以去看下我的深入理解 UUID:结构、变体与版本差异全解析这篇文章,这里不再赘述。

下面主要分析下 v7 版本的不同。

UUID v7 是由 Unix 时间戳 + 随机数组成的。它支持排序适合数据库索引。

 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
   32位    16位 16位 16位      48位

UUID v7 的前 48 位是 Unix 时间戳(毫秒精度),生成的 ID 可以按时间顺序排列。

uuid-v7

基本结构:48 位时间戳 + 4 位版本 + 2 位 变体 + 随机数

由于 UUID v7 版本把时间戳放在了最高有效位,这使得 UUID 在全局范围内呈现出单调递增的特性。这种有序性有利于 B+ 索引树优化。所以可以考虑使用 UUID v7 来做数据库的主键。

v7 版本没有 v1 版本使用的 MAC 地址,所以会更加安全生成效率也更高。v4 版本由于全随机没有顺序可言,会导致索引效率不好碎片多影响数据库插入性能。

目前PostgreSQL 18 已经引入了 UUID v7,MySQL 数据库这边还没有引入,只能通过第三方的库实现 UUID v7。

本文由 emanjusaka 创作,发表于 www.emanjusaka.com,采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。

❋

微信扫码分享

微博
点赞是美意,赞赏是鼓励。如有帮助,可以关注下微信公众号。
微信 微信
支付宝 支付宝
查看赞赏名单 →
评论
← 上一篇 Integer 类型比较大小的坑 下一篇 → 准确获取图片原始颜色模型:避免 ImageIO 自动转换的陷阱