MySQL 自增 VS UUID

引言

简介

编写开源组件，自然一切都要采用最佳实践。

在第一步，设计数据表时就遇到了问题，过去的数据表中，一直采用AUTO_INCREMENT的BigInt作为主键，也开始思考，BigInt是不是最好的呢？

注：微博、美团、微信、Twitter的业务都非自增，而是采用自己设计的分布式ID算法。

又回到了经典的问题场景，数据库设计，该用自增的Int还是UUID？

UUID

MySQL官方对UUID(Universally Unique IDentifier)的解释如下：

A UUID is designed as a number that is globally unique in space and time. Two calls to UUID() are expected to generate two different values, even if these calls are performed on two separate computers that are not connected to each other.

UUID被设计为一个在时间和空间内全局唯一的数字。UUID()方法的多次调用会生成不同的值，即便它们是在互不相连的独立的计算机上执行的。

执行语句，生成一个UUID。

SELECT UUID() as UUID

UUID的格式如下：

32个16进制数字，以-作为分隔符，格式为8-4-4-4-12，共计36个字符。

853a7583-3bf9-11ea-8dc9-f48e38f0f826

$${16}^{32}\approx{3.4}\times{10}^{38}$$

这个具体怎么生成出来的就不研究了，了解全局唯一即可。

ps：segmentfault的latex公式还挺好使！

探究

对比

参考问题：The differences between INT and UUID in MySQL - StackOverflow

参考问题：UUID performance in MySQL - StackOverflow

参考文章：美团技术分享：深度解密美团的分布式ID生成算法 - SegmentFault

如果选用了自增INT作为主键，会在特定数据库与特定数据表内返回唯一的INT值，但是并不是全局唯一的，如果该数据库被导入到其他的数据库，就会发生主键冲突。

UUID优点

性能非常高：本地生成，无网络消耗。

UUID缺点

不易于存储：UUID长度36个字符，太长。

信息不安全：UUID算法基于MAC地址生成，可能会造成MAC地址泄露。

MySQL官方建议主键越短越好。且在InnoDB引擎下，UUID的无序性会严重影响性能。

总结

看了好多关于两者对比的文章，大多数都是根本没有经过实际业务考验的纸上谈兵，但是微信、美团的技术分享还是很说明问题的。

精简下来就是UUID全局唯一，但其性能不适合大数据与高并发场景。

在数据库层面，小业务，如果不考虑数据迁移与分布式，INT自增足够了。大业务，分布式、高并发、大数据，UUID虽然能保证唯一，但性能不佳，仍需设计自定义的ID算法。

发现美团的ID算法是开源的，感谢美团：Leaf - Github