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

xuejianxinokok

于 2024-08-26 09:05:20 发布

阅读量504

点赞数 4

分类专栏： java 数据库文章标签： mysql 数据库

本文链接：https://blog.csdn.net/xuejianxinokok/article/details/141550075

版权

60 篇文章 3 订阅

订阅专栏

59 篇文章 3 订阅

订阅专栏

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

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

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

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

其他的呢？

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

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

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

参考文章: