主键的设计 uuid

妖狐艹你老母 2022-09-03 07:25 195阅读 0赞

错误的设计规范：**主键建议使用自增 ID 值，不要使用 UUID，MD5，HASH，字符串作为主键**

这个设计规范在很多文章中都能看到，自增主键的优点有占用空间小，有序，使用起来简单等优点。

下面先来看看自增主键的缺点：

*  自增值由于在服务器端产生，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈，所以存在并发性能问题；
 *  自增值做主键，只能在当前实例中保证唯一，**不能保证全局唯一，这就导致无法在分布式架构中使用；**
 *  公开数据值，容易引发安全问题，如果我们的商品 ID 是自增主键的话，用户可以通过修改 ID 值来获取商品，严重的情况下可以知道我们数据库中一共存了多少商品。
 *  MGR（MySQL Group Replication） 可能引起的性能问题；

因为自增值是在 MySQL 服务端产生的值，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈。比如在 MySQL 数据库中，参数 innodb\_autoinc\_lock\_mode 用于控制自增锁持有的时间。虽然，我们可以调整参数 innodb\_autoinc\_lock\_mode 获得自增的最大性能，但是由于其还存在其它问题。因此，**在并发场景中，更推荐 UUID 做主键或业务自定义生成主键。**

**需要特别注意的是，在存储时间时，UUID 是根据时间位逆序存储，** 也就是低时间低位存放在最前面，高时间位在最后，即 UUID 的前 4 个字节会随着时间的变化而不断“随机”变化，并非单调递增。而非随机值在插入时会产生离散 IO，从而产生性能瓶颈。这也是 UUID 对比自增值最大的弊端。

为了解决这个问题，MySQL 8.0 推出了函数 UUID\_TO\_BIN，它可以把 UUID 字符串：

*  通过参数将时间高位放在最前，解决了 UUID 插入时乱序问题；
 *  去掉了无用的字符串"-"，精简存储空间；
 *  将字符串其转换为二进制值存储，空间最终从之前的 36 个字节缩短为了 16 字节。
 *  uuid\_to\_bin(uuid(),true) 可以在将uuid转换为字符串的同时，将低位和高位的日期互换，便于排序

除此之外，MySQL 8.0 也提供了函数 BIN\_TO\_UUID，支持将二进制值反转为 UUID 字符串。

虽然 MySQL 8.0 版本之前没有函数 UUID\_TO\_BIN/BIN\_TO\_UUID，还是可以通过自定义函数的方式解决。应用层的话可以根据自己的编程语言编写相应的函数。

当然，很多同学也担心 UUID 的性能和存储占用的空间问题，这里我也做了相关的插入性能测试，结果如下表所示：

![20210806112157534.png][]

可以看到，MySQL 8.0 提供的排序 UUID 性能最好，甚至比自增 ID 还要好。此外，由于 UUID\_TO\_BIN 转换为的结果是16 字节，仅比自增 ID 增加 8 个字节，最后存储占用的空间也仅比自增大了 3G。

而且由于 UUID 能保证全局唯一，因此使用 UUID 的收益远远大于自增 ID。可能你已经习惯了用自增做主键，但是在并发场景下，更推荐 UUID 这样的全局唯一值做主键。

当然了，UUID虽好，但是在分布式场景下，主键还需要加入一些额外的信息，这样才能保证后续二级索引的查询效率，推荐根据业务自定义生成主键。但是在并发量和数据量没那么大的情况下，还是推荐使用自增 UUID 的。大家更不要以为 UUID 不能当主键了。

[20210806112157534.png]: /images/20220829/f78329c5293945189d585246f777d9b9.png