Mysql UUID_SHORT（）与UUID（）是否可比 [英] Is Mysql UUID_SHORT() comparable to UUID()
问题描述
如果愿意，可以快速提问或提出意见。
A quick question or opinion if you will.
我需要为数据库表生成一些UUID。
I need to generate some UUID's for a database table.
自动递增键不会削减它，因为我还需要该键在数据库和系统之间也是唯一的。 UUID工作正常，但是对于某些行将导出到的系统，其输出太长。 UUID_SHORT（）做得很好，我已经阅读了MYSQL关于保证其唯一性的条件。
Auto incrementing keys won't cut it as I need the key to be unique across databases and systems also. UUID works fine however its output is too long for some of the systems that the rows will be exported to. UUID_SHORT() does the job fine and I have read MYSQL's conditions on guaranteeing its uniqueness.
但是我只想再次检查一下，如果我使用UUID_SHORT（）来不时为行生成UUID，那么它们在时间和空间上的确与UUID一样唯一（）。
ButI just want to double check that if I use UUID_SHORT() to generate UUID's for rows from time to time that they will indeed be unique in time and space as with UUID().
干杯。
推荐答案
uuid_short（）产生服务器ID的按位聚集，相当静态的时间分量以及按顺序增加的24位整数。这些位填充为8字节整数。时间部分取决于服务器的启动时间。
uuid_short() produces a bitwise conglomeration of the server ID, a fairly static time component, and a sequentially increasing 24 bit integer. These bits are stuffed into an 8 byte integer. The time component is based on the server's boot time.
uuid（）生成代表16字节version1 UUID的十六进制字符串。版本1 UUID是服务器ID，当前时间戳，如果以超高速生成ID时会起作用的几个字节以及一些实用程序位的按位组合。
uuid() produces hex string that represents a 16 byte version1 UUID. Version 1 UUIDs are a bitwise conglomeration of the server ID, the current timestamp, a few bytes that come into play if you generation IDs at hyperspeed, and a few utility bits.
回答您的问题： uuid_short 是否提供了与 uuid ？答案是不。例如， uuid_short 中的服务器ID仅一个字节。因此，如果您拥有256台或更多服务器，则至少其中一些将具有相同的节点ID，这意味着您将失去空间唯一性。为了进行比较，版本1 UUID中的服务器ID为6个字节长，有效地消除了除最大的公司服务器场外所有服务器重复的机会：）
To answer your question: does uuid_short provide time and space uniqueness that rivals uuid? The answer is no. Case in point, the server ID in a uuid_short is only one byte. So if you have 256 or more servers, at least a few of them will have the same node id, which means you lose space uniqueness. For comparison, the server ID in version 1 UUID is 6 bytes long, effectively killing the chance of duplicates for all but the largest of corporate server farms :)
一个更好的问题是 uuid_short 是否足够好。如果您遇到以下情况，您可能会看到ID冲突：
A better question is whether uuid_short is good enough. You could see ID collisions if you :
- 在同一时间从同一服务器生成超过1600万个IDS。 ***
- 引导具有相同服务器ID的服务器完全同时，并在它们之间共享数据。
- 弄乱系统时钟，然后重新启动服务器。
第二个问题似乎不太可能对于大多数人来说，但是第一个值得进行调查，然后再承诺将 uuid_short 作为密钥的基础。
The second issue seems unlikely for most people, but the first one is worth investigating before you commit to making uuid_short the basis of your keys.
***根据 uuid_short 的mysql文档，如果在单个服务器的正常运行时间中生成的1600万个ID以上，似乎会出现冲突。但这将是愚蠢的。 mysql文档继续说，只要您每秒不生成1600万个ID，就可以了。这意味着，如果您用尽1600万个顺序ID，它们必须在时间戳中增加一些比特。我还没有测试过。
*** Based on the mysql docs for uuid_short, it seems like you would see collisions if you generated more than 16 million IDs during the uptime of a single server. But that would be silly. The mysql docs go on to say that you are fine as long as you don't generate 16 million IDs per second. That implies that they must bump some of the bits in timestamp if you exhaust the 16 million sequential IDs. I have not tested this.
这篇关于Mysql UUID_SHORT（）与UUID（）是否可比的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
