mysql - Mysql UUID_SHORT() 是否与 UUID() 相当

Question

如果您愿意，可以快速提问或发表意见。

我需要为数据库表生成一些 UUID。

自动递增键不会削减它，因为我还需要键在数据库和系统中是唯一的。 UUID 工作正常，但它的输出对于行将导出到的某些系统来说太长了。 UUID_SHORT() 做得很好，我已经阅读了 MYSQL 关于保证其唯一性的条件。

但我只是想仔细检查一下，如果我不时使用 UUID_SHORT() 为行生成 UUID，它们确实会像 UUID() 一样在时间和空间上是唯一的。

干杯。

Answer 1

uuid_short() 生成服务器 ID 的按位集合、相当静态的时间组件和按顺序递增的 24 位整数。这些位被填充到一个 8 字节的整数中。时间组件基于服务器的启动时间。

uuid() 生成表示 16 字节版本 1 UUID 的十六进制字符串。版本 1 UUID 是服务器 ID、当前时间戳、以超高速生成 ID 时会发挥作用的几个字节以及一些实用程序位的按位组合。

回答您的问题:uuid_short 是否提供与 uuid 相媲美的时间和空间唯一性？答案是不。例如，uuid_short 中的服务器 ID 只有一个字节。因此，如果您有 256 台或更多服务器，至少其中一些服务器将具有相同的节点 ID，这意味着您失去了空间唯一性。相比之下，版本 1 UUID 中的服务器 ID 是 6 个字节长，有效地消除了除了最大的公司服务器群之外的所有重复的机会:)

一个更好的问题是 uuid_short 是否足够好。如果您执行以下操作，您可能会看到 ID 冲突:

1. 在短时间内从同一台服务器生成超过 1600 万个 IDS。 ***
2. 同时启动具有相同服务器 ID 的服务器，并在它们之间共享数据。
3. 调整系统时钟，然后重新启动服务器。

第二个问题对大多数人来说似乎不太可能，但在您 promise 将 uuid_short 作为您的 key 的基础之前，第一个问题值得研究。

*** 根据 uuid_short 的 mysql 文档，如果在单个服务器正常运行期间生成超过 1600 万个 ID，您似乎会看到冲突。但那将是愚蠢的。 mysql 文档继续说，只要您不每秒生成 1600 万个 ID，就可以了。这意味着如果您用尽 1600 万个连续 ID，它们必须在时间戳中增加一些位。我没有对此进行测试。