Mysql UUID_SHORT（）与UUID（）是否可比

马靓仔

如果您愿意，可以快速提问或提出意见。
我需要生成一些数据库表UUID。
自动递增键不会减少它，因为我也需要它是数据库和系统之间唯一的键。UUID它可以正常工作，但对于一些行将导出的系统，它的输出太长。UUID_SHORT()我已经读完工作了MYSQL确保其独特性。
但我只想仔细检查一下，如果我不时使用它UUID_SHORT()为行生成UUID，所以他们确实在时间和空间上UUID()独一无二。
干杯。
                                                               
1 z; A: ?% C- u* \5 G$ R& t    解决方案:                                                               
" N2 Q( I8 n7 m# n9 M4 o5 t( _                                                                uuid_short()生成服务器ID按位聚集，相当静态的时间重量和顺序增加的24位整数。这些位置填充8字节整数。时间部分基于服务器的启动时间。
uuid()代表16字节version1 UUID十六进制字符串。
+ C  O9 V. F  [- p2 bUUID是服务器ID，如果当前时间戳以超高速生成ID几个字节和一些实用程序位的按位组合。
回答你的问题：uuid_short时间和空间的独特性可以与之匹敌uuid答案是否定的。a中的服务器IDuuid_short只是一个字节。所以，如果你有256个或更多的服务器，至少有一些会有相同的节点ID，这意味着你将失去空间的独特性。为了比较，版本1
( e& \# F- V9 ^/ ?9 m4 H6 \* w8 qUUID中的服务器ID除了最大的公司服务器外，所有服务器重复的机会都被有效地消除了6个字节长：）
是否有更好的问题？uuid_short足够好。如果出现以下情况，您可能会看到ID冲突：
  G( k5 g4 B! k& S8 g# u! Y8 h3 v[ol]同一台服务器在短时间内生成超过1600万台IDS。***
服务器完全相同ID引导服务器完全同时共享数据。
) u# j7 v; l! T- l' Z6 _玩系统时钟，然后重新启动服务器。[/ol]对大多数人来说，第二个问题似乎不太可能，但第一个问题值得一查，然后承诺建立uuid_short密钥基础。
***根据的mysql文档uuid_short，如果在单台服务器的正常运行时间内产生超过1600万个ID，你似乎看到了冲突。但这将是愚蠢的。mysql文档继续说，只要你每秒不生成1600万ID，就这样。这意味着，如果你用尽了1600万个顺序ID，他们必须在时间戳中添加一些比特。我还没有测试过。