UUID 的 8 个版本以及何时使用它们

有哪些不同的版本？

通常，当我们有多个编号版本时，数字越大越新，并且被认为越好。相比之下，有 8 个 UUID 版本（v1 到 v8），它们各不相同，并且全部在标准中定义。

在这里，我将提供一些关于它们的高层次解释，并链接到 RFC ，以防您需要更多详细信息。

• UUID 版本 1 (v1)由时间戳、单调计数器和 MAC 地址生成。
• UUID 版本 2 (v2)保留用于没有已知详细信息的安全 ID。
• UUID 版本 3 (v3)是根据您提供的某些数据的 MD5 哈希值生成的。 RFC 在候选数据中建议了 DNS 和 URL。
• UUID 版本 4 (v4)是根据完全随机的数据生成的。这可能是大多数人对 UUID 的想法和遇到的情况。
• UUID 版本 5 (v5)是根据您提供的一些数据的 SHA1 哈希值生成的。与 v3 一样，RFC 建议使用 DNS 或 URL 作为候选。
• UUID 版本 6 (v6)由时间戳、单调计数器和 MAC 地址生成。这些数据与版本 1 相同，但更改了顺序，以便对它们进行排序时将按创建时间排序。
• UUID 版本 7 (v7)由时间戳和随机数据生成。
• UUID 版本 8 (v8)完全是自定义的（除了所有版本都包含的必需版本/变体字段）。

什么时候应该使用它们？

有八个不同的版本，您应该使用哪个？有一些常见的用例决定了您应该使用哪个，其中一些已被其他用例取代。

您通常会在其中两个之间进行选择：v4 或 v7。也有一些场合选择v5或v8。

• 当您只想要一个随机 ID 时，请使用 v4。这是一个很好的默认选择。
• 如果您要在希望能够排序的上下文中使用 ID，请使用 v7。例如，如果您使用 UUID 作为数据库键，请考虑使用 v7。
• 如果您在 UUID 中有自己想要的数据，则使用 v5 或 v8，但一般来说，您会知道是否需要它。

其他的呢？

• 根据 RFC ，v7 在 v1 和 v6 的基础上进行了改进，如果可能的话，应该使用 v7。所以你通常不需要 v1 或 v6。如果您确实想要其中之一，可以使用 v6。
• v2 保留用于未指定的安全事务。如果您正在使用这些，您可能无法告诉我或其他任何人，并且您可能不会阅读这篇文章来了解有关它们的更多信息。
• v3 被 v5 取代，后者使用更强的哈希值。您可能知道是否需要它。

UUIDv7 的优点：

• 时间可排序性：如上所述，UUIDv7 值是可时间排序的，这意味着您可以根据生成时间以升序对它们进行排序。这使得基于时间的查询更加高效和直观。
• 精确时间戳：从之前的草案开始，UUIDv7 的粒度高达 50 纳秒（但在编写时默认为 1 毫秒，请参阅RFC4122 草案），UUIDv7 提供出色的精度。当与随机性相结合时，这基本上保证了碰撞（即使在全球分布式系统之间！）是不可能的。
• 全球唯一性：与其他 UUID 一样，UUIDv7 确保全球唯一性。这意味着您可以跨不同系统或节点独立生成 ID，并且它们不会发生冲突。

为什么 UUIDv7 更适合数据库：

• 自然排序：传统数据库通常需要额外的时间戳列来根据创建时间对记录进行排序。借助 UUIDv7，您可以使用 UUID 本身实现这种排序，从而无需额外的列。
• 优化索引：由于 UUIDv7 是可时间排序的，数据库索引机制可以更好地优化存储和检索过程，从而加快查询时间，尤其是基于时间的查询。
• 并发和分布：在分布式系统中，生成唯一的、连续的 ID 可能是一个挑战。 UUIDv7 可以跨多个节点同时生成，没有冲突的风险，使其适合分布式架构。
• 减少开销：与 UUIDv1 不同，UUIDv1 可以公开生成 UUID 的计算机的 MAC 地址（引发隐私问题），UUIDv7 没有这个缺点，减少了模糊或匿名化此数据的开销。
• 灵活性：支持二进制存储的数据库可以有效地存储UUIDv7，并且如果需要，可以轻松地将它们编码为其他格式，例如字符串。

参考文章:

原文地址

# UUIDv7：现代数据库的时间可排序标识符