9

一个快速的问题或意见，如果你愿意的话。

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

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

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

干杯。

4

2 回答 2

11

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

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

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

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

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

对于大多数人来说，第二个问题似乎不太可能，但第一个问题值得在您承诺制作uuid_short密钥的基础之前进行调查。

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

于 2015-01-08T20:42:18.800 回答
4

你的关键问题是，确实UUID_SHORT()创造了在时间和空间上独一无二的价值UUID()。简短的回答是肯定的，只要你遵守 MySQL 要求的特殊条件。

长答案是肯定的，但你为什么要使用它？唯一明显的缺点UUID()是它的表示存储效率较低（生成 36 个字符的字符串而不是 64 位整数），并且不能用于基于语句的复制。但是UUID()有一个很大的好处，那就是永远不必考虑 MySQL 需要的特殊条件UUID_SHORT()。如果您确定条件对您来说永远不会成为问题，并且您渴望保存每条记录的所有 224 位，UUID_SHORT()则可以使用。但是，如果您对特殊情况有任何疑虑，那么最好避免它。

您对特殊条件的关注程度在很大程度上取决于您的操作环境。在重新启动之间永远不要向后设置系统时钟的要求mysqld对我来说是一个大问题。服务器通常配置为使其时钟与其他时间源自动同步（例如ntp，在 unix 中，Windows 中的时间服务），如果此行为未达到您的预期，那么您可能无法保证该条件得到一致的满足。

于 2013-09-30T13:21:16.290 回答