如果您愿意,可以快速提问或提出意见。

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

自动递增键不会削减它,因为我还需要该键在数据库和系统之间也是唯一的。 UUID可以正常工作,但是对于某些行将导出到的系统而言,其输出太长。 UUID_SHORT()可以很好地完成工作,我已经阅读了MYSQL保证其唯一性的条件。

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

干杯。

最佳答案

uuid_short()产生服务器ID的按位聚集,相当静态的时间分量以及按顺序增加的24位整数。这些位填充为8字节整数。时间部分基于服务器的启动时间。
uuid()产生代表16字节version1 UUID的十六进制字符串。版本1 UUID是服务器ID,当前时间戳,如果以超高速生成ID时会起作用的几个字节以及一些实用程序位的按位组合。

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

更好的问题是uuid_short是否足够好。如果出现以下情况,您可能会看到ID冲突:

  • 在短时间内从同一服务器生成超过1600万个IDS。 ***
  • 具有完全相同服务器ID的引导服务器都完全在同一时间,并在它们之间共享数据。
  • 拨弄系统时钟,然后重新启动服务器。

  • 对于大多数人来说,第二个问题似乎不太可能,但是在您致力于使uuid_short成为 key 的基础之前,第一个问题值得研究。

    ***基于mysqlt文件的uuid_short,如果您在单个服务器的正常运行时间内生成了超过1600万个ID,则似乎会看到冲突。但这将是愚蠢的。 mysql文档继续说,只要您每秒不生成1600万个ID,就可以了。这意味着,如果您用尽1600万个顺序ID,它们必须在时间戳中增加一些比特。我还没有测试。

    关于mysql - Mysql UUID_SHORT()与UUID()是否可比,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/12818671/

    10-12 20:58