MySQL主键设计

一、自增ID的问题

自增ID做主键，简单易懂，几乎所有数据库都支持自增类型，只是实现上各有所不同而已。自增ID除了简单，其他都是缺点，总体来看存在以下几方面的问题：

1. 可靠性不高
存在自增ID回溯的问题，这个问题在MySQL 8.0 版本才修复。

2. 安全性不高
对外暴露的接口可以非常容易猜测对应信息。比如：/User/1/ 这样的接口，可以非常容易猜测到用户ID的值为多少，总用户数量有多少，也可以非常容易地通过接口进行数据的爬取。

3. 性能差
自增ID的性能较差，需要在数据库服务端生成。

4. 交互多
业务还需要额外执行一次类似 last_insert_id() 的函数才能知道插入的自增值，这需要多一次的网络交互。在海量并发系统中，多1条SQL，就多一次性能上的开销。

5. 局部唯一性
最重要的一点，自增ID是局部唯一，只在当前数据库实例中唯一，而不是全局唯一，在任意服务器件都是唯一的。对于目前分布式系统来说，这完全不能满足使用。

---

二、业务字段做主键

不建议使用业务字段做主键，因为无法预测在项目后面使用中，会不会出现该字段数据重复的情况出现。

---

三、主键设计原则

1. 非核心业务

可以使用主键自增ID，如告警、日志、监控等信息。

2. 核心业务

主键设计至少应该是全局唯一且是单调递增。全局唯一保证在各系统之间都是唯一的，单调递增是希望插入时不影响数据库性能。

---

四、淘宝主键设计猜想

这里引用下别人的示例，猜测淘宝订单主键设计，具体验证也没有什么根据，个人觉得这个设计挺好，简单记录下方便以后查看。

订单ID = 时间 + 去重字段 + 用户ID

解释：

• 时间：为获取当前时间，使得ID前部分递增的
• 去重字段：这个需要根据自己业务调整选择
• 用户ID：用户ID是唯一的，可以避免ID前面部分可能偶发相同的概率

这样设计很好，整个订单ID是全局唯一且是自增的，满足数据库插入性能。

---

五、使用UUID做主键

在实际项目中，可能很多人会使用UUID做主键，保证了数据唯一性，但插入性能差，下面详细说下UUID做主键以及优化。

1. UUID介绍：

在UUID中时间部分占用60位，存储的类似TIMESTAMP的时间戳，但表示的是从1585-10-15 00:00:00 到现在的100ns的计数。可以看到UUID存储的时间精度比TIMESTAMP更改，时间维度发生重复的概率降低到1/100ns。时钟序列是为了避免时钟被回拨导致产生时间重复的可能性。MAC地址用于全局唯一。

UUID的插入性能差是因为它是随机无序的，因为UUID的设计是将时间位放在前面，而这部分数据是一直在随机变化，无序的，这样去储存到数据库中因为主键存储是以自增方式存放，无序的主键会导致页分裂影响到数据库性能。

2. UUID改造

既然UUID保证了无序，全局唯一，只差一个非自增影响了插入性能，那么可以想办法将其改造为自增的UUID，上面提到UUID是因为将时间位放在了前面，所以导致了无序，那么只要将时间低位与高位交换，那么就使得UUID为递增状了。

在MySQL 8.0 版本后可以更换时间低位和时间高位的存储方式，使得UUID为递增状，另外MySQL 8.0还解决了UUID存在空间占用的问题，除去了UUID字符串中意义的 “-” 字符串，并且将字符串用二进制类型保存，这样储存空间降低为16字节。

MySQL 8.0提供uuid_to_bin函数可以实现UUID转二进制为16字节，还可以实现时间高低位调整。

set @uuid = UUID();

SELECT @uuid,uuid_to_bin(@uuid),uuid_to_bin(@uuid,TRUE);

可以看到，在使用uuid_to_bin调整时间顺序后，UUID时间高位与低位调整了。

---

小结

这篇文章所说的主键设计，是从数据库角度考虑以及实现，在实际业务中确实很有必要设计主键为全局唯一且递增的，实际实现中，可以不用文章中介绍在SQL中去实现UUID改造这些，实际开发中，我们可能会使用更多的主键生成在代码逻辑中实现的，很少会放在SQL端实现，如经典的雪花算法就完全满足主键的设计思想，也可以参考淘宝订单ID的设计，或者有其他好的设计方案，可以评论分享。