UUID 是什么？

怎样读懂一个 UUID

文本形式共 36 个字符：32 个十六进制数字加 4 个连字符，按 8-4-4-4-12 分组。二进制形式为 16 个字节。每个 UUID 都有两个位置携带元数据：

• 版本：第三组的第一位数字。在 f47ac10b-58cc-4372-a567-0e02b2c3d479 中是 4。
• 变体：第四组的第一位数字。标准 UUID 的这一位是 8、9、a 或 b；这里是 a。

GUID 是微软对同一事物的叫法，格式完全相同。十六进制大小写等价；RFC 9562 建议输出用小写、输入不区分大小写。另有两个特殊值：全为零的 Nil UUID，以及全为 f 的 Max UUID。

UUID 的各个版本

RFC 9562 于 2024 年 5 月发布，取代了 RFC 4122，保留了版本 1 到 5，并新增了版本 6、7 和 8。

版本 3 和 5 是确定性的：用 DNS 名称的命名空间对 example.com 做哈希，在任何机器上都得到同一个 UUID。它们使用 MD5 和 SHA-1 只是为了打散位，并非出于安全目的。

版本 4 与版本 7 对比

RFC 中的版本 7 示例是 017f22e2-79b0-7cc3-98c4-dc0c0c07398f。它的前 12 位十六进制数 017f22e279b0 表示 Unix 纪元后 1,645,557,742,000 毫秒，即 2022-02-22 19:22:22 UTC。

两者在实际中的区别在于数据库性能。随机的 v4 键会落在 B 树索引的随机位置，导致页分裂，写入分散到整个索引。按时间排序的 v7 键则追加在末尾附近，和自增整数很像，插入速度快，索引也更紧凑。新建数据库主键时，v7 通常是更好的选择；对于不应暴露创建时间的不透明令牌，请用 v4。

「唯一」到底有多唯一？

122 个随机位意味着版本 4 UUID 约有 5.3 × 10^36 种可能。根据生日界限，大约要生成 2.7 × 10^18 个，出现一次碰撞的概率才会达到 50%。每秒生成十亿个，也需要大约 86 年。

现实中的碰撞来自糟糕的随机源，而不是数学本身。用相同随机状态克隆出来的虚拟机，或者基于 Math.random() 这类非密码学函数的生成器，都可能产生重复值。请使用密码学安全的随机源：浏览器和 Node.js 中的 crypto.randomUUID()，Python 中的 uuid.uuid4()，或 PostgreSQL 中的 gen_random_uuid()。

如何存储 UUID

• 有原生类型就用原生类型，比如 PostgreSQL 的 uuid：只占 16 个字节，而文本要 36 个。
• 在 MySQL 中用 BINARY(16) 存储；用文本存储会让索引大小翻倍以上。
• 比较 UUID 时不区分大小写，或在输入时统一转为小写。
• 不要试图从 v4 UUID 中解析出含义。只有版本位和变体位携带信息。