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吗？答案是不.例如,a中的服务器ID uuid_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,他们必须在时间戳中碰到一些比特.我没有测试过这个.