UUID标准说明
UUID的标准形式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID。
- UUID Version 1：基于时间的UUID
基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址，这个版本的UUID可以保证在全球范围的唯一性。
- UUID Version 2：DCE安全的UUID
DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。
- UUID Version 3：基于名字的UUID（MD5）
基于名字的UUID通过计算名字和名字空间的MD5散列值得到。
- UUID Version 4：随机UUID。
根据随机数，或者伪随机数生成UUID。
- UUID Version 5：基于名字的UUID（SHA1）
和Version 3的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。
【优点】
- 非常简单，本地生成，代码方便，API调用方便。
- 性能非高。生成的id性能非常好，没有网络消耗，基本不会有性能问题。
- 全球唯一。在数据库迁移、系统数据合并、或者数据库变更的情况下，可以 从容应对。（单机多进程会造成重复）
【缺点】
- 存储成本高。UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。如果是海量数据库，就需要考虑存储量的问题。
- 信息不安全。基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
- 不适用作为主键。ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用。UUID往往是使用字符串存储，查询的效率比较低。
- UUID是无序的。不是单调递增的，而现阶段主流的数据库主键索引都是选用的B+树索引，对于无序长度过长的主键插入效率比较低。
- 传输数据量大。
- 不可读。
需要更换雪花算法ID
版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明UUID为什么不用在分布式系统！
