如果你愿意，可以快速提问。
我需要为数据库表生成一些UUID。
自动递增密钥不会削减密钥，因为我需要密钥在数据库和系统之间也是唯一的。 UUID工作正常，但是对于某些将导出行的系统，其输出太长。 UUID_SHORT（）工作正常，我已经阅读了MYSQL的条件，以保证其唯一性。
但我只想仔细检查一下，如果我使用UUID_SHORT（）来不时地为行生成UUID，那么它们在时间和空间上确实是唯一的，就像UUID（）一样。
干杯。
答案 0 :(得分：7)
uuid_short()产生服务器ID的按位集合，相当静态的时间分量和顺序增加的24位整数。这些位填充为8字节整数。时间组件基于服务器的启动时间。
uuid()生成表示16字节版本1 UUID的十六进制字符串。版本1 UUID是服务器ID，当前时间戳，在超高速生成ID时会发挥作用的几个字节以及一些实用程序位的按位集合。
回答你的问题：uuid_short是否提供了与uuid相媲美的时间和空间唯一性？答案是不。例如，uuid_short中的服务器ID只有一个字节。因此，如果您有256个或更多服务器，则至少其中一些服务器具有相同的节点ID，这意味着您将失去空间唯一性。为了进行比较，版本1 UUID中的服务器ID长度为6个字节，有效地消除了除最大的企业服务器场之外的所有服务器重复的可能性：）
更好的问题是uuid_short是否足够好。如果您：
对于大多数人来说，第二个问题似乎不太可能，但在您承诺将uuid_short作为密钥的基础之前，第一个问题值得研究。
***基于uuid_short的mysql文档，如果您在单个服务器的正常运行时间内生成了超过1600万个ID，您似乎会看到冲突。但这很愚蠢。 mysql文档继续说你很好，只要你不能每秒产生1600万个ID。这意味着如果你耗尽了1600万个连续ID，他们必须在时间戳中碰到一些比特。我没有测试过这个。
答案 1 :(得分：3)
您的关键问题是，UUID_SHORT()是否创建了时间和空间中唯一的值，与UUID()一样。简短的回答是肯定的，只要你遵守MySQL要求的特殊条件。
答案很长，但为什么要使用呢？ UUID()唯一明显的缺点是它的表示效率较低（生成36个字符的字符串而不是64位整数），并且不能与基于语句的复制一起使用。但UUID()有一个很大的好处，就是永远不必考虑MySQL UUID_SHORT()所需的特殊条件。如果您确定条件永远不会成为您的问题，并且您渴望保存每条记录的所有224位，UUID_SHORT()可以使用。但如果您对特殊情况有任何疑虑，那么最好避免它。
您对特殊情况的关注程度在很大程度上取决于您的运营环境。在mysqld重启之间从不设置系统时钟的要求对我来说是一个很大的问题。服务器通常配置为使其时钟与其他时间源（例如，unix中的ntp，Windows中的时间服务）自动同步，如果这种行为没有按照您的期望执行，那么您可能不是能够保证一致地满足条件。