一、自增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的设计，或者有其他好的设计方案，可以评论分享。