关于数据库主键的选择方案：自增长 or UUID??

1. 问题提出

今天在看《mysql45讲》的时候，里面讲到这样一个例子：

假设你的表中确实有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键呢？由于每个非主键索引的叶子节点上都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约 20 个字节，而如果用整型做主键，则只要 4 个字节，如果是长整型（bigint）则是 8 个字节。

显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。
所以，从性能和存储空间方面考量，自增主键往往是更合理的选择。

然而，我在接触到公司的项目里，看到大多都是采用32的UUID来做主键的。由此，心生困惑，便向群里们的大佬请教了一番。

 

2. 问题探讨

首先，有好几位大佬都表示，他们公司的项目里没有使用UUID来做主键的。

其中，春少表示，使用UUID插入速度慢，会导致频繁页分裂，最好就是有序的，自增的id。就跟写文件一样，顺序写入，性能会比随机写入好，UUID就相当于随机写入，普通业务看不出来，但是业务上去的话，插入这边就存在大量的性能问题了。

这里补充一下，什么是页分裂。就是说，如果某个数据页满了，根据 B+ 树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去，这个过程称为页分裂。再结合开通引入的那段话，就很容易明白为什么UUID会导致频繁的页分裂。

然后，天舒分享了网上别人对这两个的对比，链接：https://blog.csdn.net/caodongfang126/article/details/76977942。该文章分析使用自增长和UUID的优劣，感兴趣的朋友可以好好看一下。

 

3. 问题结论

总之，在可以使用自增长ID解决问题的情况下，还是建议使用自增长ID做主键。如果自增长ID无法满足业务需求，再考虑使用UUID，当然，也可以先去了解一下上面分享的那篇文章中提到的snowflake。

 

题外话

借这个事情，想说一些题外话，对于刚毕业的同学出来找工作，如果能进大公司的话，还是选择大公司，即使某些方面可能没达到你的满意。就拿这次探讨的问题来说，在大公司会有比较周密的考虑。另外，在大公司里，你会接触到的项目开发都比较规范，无论是从见识还是学习上，对你都会有很大帮助，尤其是之前没有过任何工作经验的人来说，规范很重要。如果把找工作当做一次新的出生，那么进入大公司，就相当于生活在皇族，你会见识到很多高大上的东西。进入小公司，就相当于生活在很普通的社会阶层。当然，小公司也有好的地方，由于项目分工没那么明确，你会接触到项目的方方面面，也会掌握到很多东西。