UUID v7 生成器
UUID 生成器 的预设方案
生成按时间排序的 UUID v7 标识符——在 RFC 9562 中被标准化、用作数据库主键的版本。因为时间戳位于值的前导部分,连续的插入操作能保持连续,你的索引不会像随机的 v4 主键那样出现碎片化。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何UUID 生成器
- 1
选择一个版本
v4 适合通用随机 ID,v7 适合会作为数据库主键的 ID。
- 2
设置生成数量
一次生成从一个到一千个不等。
- 3
复制或下载
把列表复制到剪贴板,或下载为文本文件。
为什么 v7 迟至 2024 年才被标准化
多年以来,既想要 UUID 的抗碰撞性、又想要顺序整数那种对索引友好的排序性的工程团队,不得不自己构建一套非标准的混合方案——通常的做法是给一个随机 UUID 加上手动生成的时间戳前缀,在任何官方标准出现之前,好几家知名的分布式系统公司都以各自的形式采用过这种做法。RFC 9562 把这种模式正式确立成一个官方的 UUID 版本,专门是为了让不同语言和数据库的实现,都能产出并识别同一种按时间排序的结构,而不需要每个团队各自独立地重新发明一种略有不同、彼此不兼容的变体。
时间戳究竟位于这个值的哪个位置
一个 v7 UUID 的前导 48 比特编码的是以毫秒为单位的 Unix 时间戳,这正是让这个值具备排序性的原因——把两个 v7 UUID 当作普通字符串比较,能正确反映出哪一个是先生成的,因为时间戳部分在比较中占主导地位。剩余的比特依然填充着密码学随机数据,和 v4 完全一样,所以这个值在抗猜测性上,和一个完全随机的 UUID 一样强;改变的只是它的排序行为,而不是它的不可预测性。
"对索引友好"对一个实际应用来说意味着什么
除了单纯的插入速度之外,一个按时间排序的主键还有第二个日常实际用得上的好处:一个简单的 `ORDER BY id` 查询,就能自然地按创建顺序返回各行数据,不需要一个单独的 `created_at` 列,也不需要为它额外建一个索引才能按时间顺序排列记录。对于一张经常按"最新在前"查询的表来说——一份活动日志、一个队列、一份审计记录——一个 v7 主键把这种排序作为 ID 本身的附带效果免费提供,而不是作为一项需要单独维护的成本。
常见问题
UUID v4 和 v7 有什么区别?
v4 完全是随机的。v7 会把一个毫秒级时间戳放进它的前导比特里,所以后生成的 ID 排序会排在先生成的后面。两者在实际使用中都同样不可预测;v7 只是恰好同时具备了有序性。
数据库主键应该用哪一个?
用 v7。随机的 v4 主键会把插入操作分散到整个 B 树索引的各个位置,导致索引碎片化,在规模变大后显著拖慢写入速度。v7 主键会按顺序追加,所以插入操作能保持连续——这正是 v7 在 2024 年被标准化的原因。
两个 UUID 有可能相同吗?
在数学上可能,但实际上不会。一个 v4 UUID 有 122 个随机比特;你需要生成大约 2.7 × 10^18 个才会让碰撞变得有可能发生。作为对比,这个数字比地球上所有沙粒的数量还要多。
这些 UUID 生成得安全吗?
安全。它们使用的是 `crypto.getRandomValues`,也就是你操作系统的密码学随机源,而不是 `Math.random`。如果一个 UUID 会被用作某种能力令牌——一个分享链接、一个取消订阅的 URL、一个密码重置密钥——这一点就很重要。
UUID 和 GUID 是同一个东西吗?
是的。GUID 是微软对同一种 128 位标识符的叫法。你会遇到的唯一区别是格式:微软的工具经常会给它加上花括号并使用大写,这两种格式这个工具都能生成。