jpa 生成uuid的主键_UUID 及其在 MySQL 中的使用

分手后的思念是犯贱 2023-01-05 12:11 204阅读 0赞

![ffc05b00f3f6ff8583d85634fb191828.png][]

### 1. UUID 是什么？ ###

UUID（**U**niversally **U**nique **Id**entifier 通用唯一识别码）用于标识资源唯一性。理论上说，门牌号、电话号码、邮编、身份证号都是用来标识资源唯一性的，但为使用方便，不适合用一个无规律的字符串表示，UUID 主要还是在程序中使用。

UUID 源自1980年代的 Apollo 电脑公司，是一个 128 位的标识符，理论上的总数有 2128个，也就是说，哪怕每纳秒产生 1 万亿个 UUID，也要 100 亿年才能用完。因此，只要保证生成方法的散布足够好，统计概率上，UUID 重复的可能性约等于 0 。

UUID 的具体规范可以参考 RFC 4122。这个标准定义了 5 个版本的 UUID：

1.  **版本 1 根据时间和 MAC 地址来生成 UUID。**MAC 地址用于保证设备唯一性。通过在时间戳后加入 13-14 位的时钟序列，可以保证在同一台设备，同 1 秒内生成的 1630 亿个 UUID 不重复。  
    这个版本的 UUID 我们用得相对较少，一个原因是其中携带了设备信息。1999 年，著名病毒梅丽莎的作者，因为代码中的 UUID 暴露了 MAC 地址信息，不到一个星期就被抓住了。另一个原因是这个版本的 UUID 生成有规律，比较容易根据一个 UUID 推断到下一个 UUID。
2.  **版本 2 是一个 DEC 安全的版本**，RFC4122 中也没有详细说明具体实现方式，我们一般也用不到。
3.  **版本 3 根据字符串和命名空间散列值（HASH）来获取 UUID。**由于 HASH 函数本身的特性，一般不用担心 UUID 冲突，或者别人根据散列值反推原数据的问题。这个版本采用的是 MD5 散列值。
4.  **版本 4 根据随机数生成 UUID**，是我们比较常用的版本。
5.  **版本 5 和版本 3 一样，也是根据散列值获取 UUID**，不过采用的散列算法是 SHA-1 而不是 MD5，相较而言，RFC4122 推荐大家使用版本 5 而不是版本 3。

我们常看到的 UUID 往往被表示为 16 进制数字和横杠组成的字符串，比如：`a3535b78-69dd-4a9e-9a79-57e2ea28981b`，其中第二个横杠之后的第一个数字表示 UUID 版本，例子中这个 UUID 就是版本 4 的。

--------------------

### 2. 为什么在数据库中使用 UUID？ ###

大多数人在数据库中存储 UUID 的直接原因，是需要一个不暴露内部信息的唯一标识。例如博客文章，`Title` 无法保证不重复，数字 `ID` 则会暴露内部信息，于是，可以生成一个 UUID 作为唯一标识。类似地，我们在网上请求的许多公开资源，如图片、音频、以及其他文件等，都是以 UUID 作为标识的。

第二个原因，是为了方便数据管理：

1.  当数据量过大，不得不进行分片管理的时候，数字 ID 的唯一性不好保证；万一需要重建部分数据，数字 ID 也很难确保与原表一致。
2.  UUID 作为预先生成的值，可以在插入数据库之前拿到，会方便一些数据操作。

--------------------

### 3. UUID 作为主键有什么问题？ ###

一般不推荐把 UUID 作为主键，它会带来不少问题：

### 3.1 数据碎片化 ###

我们知道，使用自增 ID 作为主键时，插入新的数据行往往是连续的，插入多条数据只需要读写少数数据页。但由于 UUID 的随机性，新插入的数据往往会落在不同的数据页上，导致数据碎片化，同样的数据量，可能需要更大的空间才能存储。

同时，当数据量上升，内存中无法暂存足够多的数据页时，每次插入数据都可能涉及硬盘读写，极大地拖慢了数据插入效率。

### 3.2 索引占用空间过大 ###

大多数人会把 UUID 保存为 16 进制数字和横杠组成的字符串，也就是 char(36)，如果采用 UTF-8 字符集，它所占的字节数是 2 + 3 \* 36 = 110 字节（前面 2 个字节为长度，后面每个字符 3 个字节）。相较而言，一个整数只有 4 个字节，相差 27 倍。

数据库采用 B 树索引，其中主键索引的叶子节点指向数据行，而二级索引的叶子节点存储着主键，之后再通过主键索引回表查数据。也就是说，有多少个二级索引，主键就需要被存储几次，因此，索引的空间需求就极速扩张了。

在数据库运行过程中，为加快查询速度，这些索引往往需要被加载到内存中。那么，过大的索引导致内存不足，就会严重影响数据库查询效率。

### 3.3 字符比较比整数比较慢 ###

CPU 每次最多可以比较 8 个字节的整数值，但对于字符串，必须一个字符一个字符比较过去。有测试说明，在查询比较时，使用整数的速度比使用字符串的速度快数倍到数十倍之间。

不过，一般来说，数据库不是一个 CPU 密集的应用，因此这方面的影响不是主要考虑因素。

--------------------

### 4. 替代方案讨论 ###

### 4.1 优化 UUID 的存储 ###

将 UUID 存储为 16 进制值和横杠组成的字符串是非常低效的，UUID 本身只有 128 位，也就是 16 字节，存储成字符串后却有 110 个字节，膨胀了 7 倍，凭空多占了不少空间。优化的思路就是采用更好的格式，比如直接存储二进制，或者将二进制值存储为 base64 字符串。相对复杂一点的是将 UUID 映射到一个整数。

优化存储格式的具体实现都不困难，也能相当程度地节约存储空间，但并没有解决 UUID 的随机性带来的数据碎片化的问题。

针对碎片化的问题，有一个思路是控制随机性，也就是增加一个自己生成的字符串作为前缀，比如说日期（或它的哈希值）。因为字符串排序从前往后走，同样的前缀也就意味着接近的排序，那么，原本散布在整个数据库的值，就会集中分布在一定范围内的数据页，从而大大缓解了内存压力。

### 4.2 同时使用自增 ID 和 UUID ###

更常见的思路，是使用自增 ID 作为主键，同时使用 UUID 作为唯一标识和与其它表关联的外键。好处是有了一个可以比较安全地对外暴露的唯一标识，节约了索引空间，也不用担心数据分片和数据重建带来的危险。

但也存在一些问题，因为所有的外键关联都用的 UUID，所以占用的空间自然会大一些，同时，字符串比较速度较慢和所有查询都要回表也是值得考虑的因素。

### 4.3 避开 UUID ###

很多小型应用不需要考虑数据管理的问题，只是需要一个可以对外暴露的唯一标识，于是，干脆放弃 UUID，采用其他思路实现标识的唯一性。

比如说前面说的博客文章，鉴于 Title 没法保证唯一性，可以在 Title 前后加上一个前缀或者后缀，从而实现唯一性。一个思路是使用随机字符串，或者作者、日期等信息。

又比如说，将每个数据行映射到一个大整数作为唯一标识。某种意义上等于根据自己的实际需要写了一套新的唯一标识算法。

--------------------

参考链接：

*  通用唯一识别码
 *  RFC 4122
 *  UUID 很火但性能不佳？今天我们细聊一聊（感谢译者，不过本文有一些翻译小错误，如把 6B 看成了 6M 等）