UUID是可以生成时间、空间上都独一无二的值，其本质是随机+规则组合而成的。即使在两个独立的服务器上生成UUID，其预期值也是不同的。以MySQL为例，说明下UUID。
在MySQL中，UUID值是一个128位的数字，表示为以下格式的十六进制数字的utf8字符串：aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee。其得到的随机值由5个部分组成，且分隔符位为：中划线。其各部分含义如下：
- 前三组值是时间戳换算过来的；
- 第四组值是暂时性保持时间戳的性。例如，使用夏令时；
- 第五组值是一个IEE 802的节点标识值，它是空间上的。若后者不可用，则用一个随机数字替换。假如主机没有网卡，或者我们不知道如何在某系统下获得机器地址，则空间性就不能得到保证，即使这样出现重复值的几率还是非常小的。
在MySQL环境中多次调用或执行得到的后两组值相同，若把mysqld服务器关闭，重新启动之后，会发现第四组的组与未重启前的值发生变化，然后一直不变化，只要重新启动mysqld服务就会发生变化。另外，对于同一台机器，第五组值始终不会发生变化。
使用UUID作为主键具有以下优点：
- UUID值在表，数据库甚至在服务器上都是的，允许您从不同数据库合并行或跨服务器分发数据库。
- UUID值不会公开有关数据的信息，因此在URL中使用更安全。
- 可以在避免往返数据库服务器的任何地方生成UUID值。它也简化了应用程序中的逻辑。
❖ 缺点
除了优势之外，UUID值也存在一些缺点：
- 存储UUID值(16字节)比整数(4字节)或甚至大整数(8字节)占用更多的存储空间。
- 调试似乎更加困难，想象一下WHERE id ='9d6212cf-72fc-11e7-bdf0-f0def1e6646c'和WHERE id = 10哪个舒服一点？
- 使用UUID值可能会导致性能问题，因为它们的大小和没有被排序。
❖ 数据库案例：MySQL
在MySQL中，就内置了对UUID的支持。在使用上需注意若干问题。
- 作为主键问题UUID()函数产生的值，并不适合作为InnoDB引擎表的主键。因为格式无序，作为索引组织表存储会带来管理上的不小开销。
- 格式问题在MySQL中，可以使用UUID()来生成主键，但是用MySQL的UUID()函数 ，生成的UUID是36位的，其中包含32个字符以及4个分隔符（-），往往这个分隔符对我们来说是没有用的，可以使用MySQL自带的REPLACE函数去掉分隔符。
- 内置函数支持在MySQL中，可以以紧凑格式(BINARY)存储UUID值，并通过以下功能显示人机可读格式(VARCHAR)：UUID_TO_BIN、BIN_TO_UUID、IS_UUID。需要注意，UUID_TO_BIN()，BIN_TO_UUID()和IS_UUID()函数仅在MySQL 8.0或更高版本中可用。
- UUID_TO_BIN()函数将UUID从人类可读格式(VARCHAR)转换成用于存储的紧凑格式(BINARY)格式
- BIN_TO_UUID()函数将UUID从紧凑格式(BINARY)转换为人类可读格式(VARCHAR)
- IS_UUID()函数则可用来判断参数是有效的字符串格式
UUID。
