最近在使用数据库要建表选择主键的时候，突然想到经常使用的两类主键id——自增id和UUID有什么区别，用那种更好？之前使用MySql的时候通常直接就选择了自增id了，工作的时候也看到有些项目使用UUID做主键，但是都没怎么考虑两者的区别，优缺点之类的。现在要键新表选择主键的时候，就需要考虑选择哪种做主键了，因此就有了这篇文章

本文首先分别简单为什么数据库需要主键，然后介绍自增id和UUID，接着比较两者的区别，最后给出何时使用哪种类型做主键更好。

关系型数据库中的主键

在关系型数据库模型中，关系型数据库是一组具有很多行数据的表组成的，这些不同的表之间通过key关联起来，包括主键primary key和外键foreign key。

主键用来唯一标识出在一张表中的某一条数据，在数据库中设置了主键约束的列数据库引擎会保证其唯一性。外键则是在另外的表中存储的其他表的主键的列。通过主键和外键就可以将数据库中不同的表关联起来。

为了应对业务场景的变化，通常将主键的值设置为与业务无关的量，也就是本文所讨论的自增id和UUID。

简单总结一下就是为了唯一标识表中的一行数据需要主键，为了使多个表关联起来需要使用外键，为了与业务解耦，需要采用与业务无关的值作为主键。

自增ID

自增ID简单的说就是在向表中插入一条数据时不用自己设置id的值，数据库引擎会自动根据表中的数据的id+1进行填充。

由于是数据库引擎负责生成的主键id，因此不需要我们自己处理主键重复的问题，同时生成比较简单，速度快，并且因为是增量生成的，在插入和查找数据的时候可以比使用随机的值具有更好的性能。

以MySQL为例，数据存储在主索引（B+树）的叶子节点上，因此同一叶子节点的各条数据继续需要按主键顺序进行存储，当由一条新的数据插入的时候，如果向新数据的主键处于已有数据主键的中间值，可能需要为了将新数据插入到对应的位置而移动数据，会增加额外的开销。

同时由于id是根据插入的顺序递增的，对开发人员来说，在某种程度上会比使用近乎随机值的UUID更加直观。而且相比UUID需要128位进行存储，自增id通常仅需要使用64位的无符号整型(0,18446744073709551615)就可以满足绝大部分的场景需求。

UUID

UUID——通用唯一标识码（Universally Unique Identifier）

UUID最早由Apollo Computers在1990年提出，随后由OSF（Open Software Foundation）标准化。UUID有128位组成，通常表示为32个16进制数。

UUID到目前为止有5个版本，具体可以查看UUID的规范、v1-v5以及如何保证唯一性

这里简单说一些各个版本的区别：

1. UUID v1 基于时间戳和MAC地址生成，但时间精度不足时使用clock sequence来扩展时间戳。由于此版本依赖于设备供应商提供唯一的MAC地址，因此可以通常它反查到对应的MAC地址
2. UUID v2 没有提供实现细节，基本很少使用
3. UUID v3,v5 都是通过hash namespace的标识符和名称生成的，不同在于v3使用MD5作为hash函数，v5使用SHA-2做hash函数。当输入的namespace与参数相同时会输出相同的UUID。
4. UUID v4 除了4位表示版本和2-3位标识varant外，其余位全部随机。这是用得最广泛的版本

五个版本都可以保证唯一，但是不管是那个版本生成的UUID，对数据库而已生成的UUID值都近乎随机。

自增ID与UUID的比较

1. 自增ID是有序的，而UUID是随机的。前面已经说了，如果主键是有序的，数据库可以具有更好的性能（至少对MySQL而已是如此）
2. 自增ID所需的存储空间比UUID要小
3. 由于自增ID比UUID更加简单，因此生成自增ID的生成速度也比UUID更快
4. 自增ID与数据相关，主键会暴露出去的话，自增ID会显示当前表中的数据规模；而UUID则无此风险
5. 自增ID在不同的数据库中可能重复，在分布式的环境下无法保证唯一。而UUID在分布式环境下也可以保证唯一

具体而已，自增ID在性能上更有优势，而UUID则更加适应分布式场景

何时使用自增ID，何时使用UUID

如果数据量非常大需要分库，或者需要更好的安全性，那么使用UUID
对于非敏感数据或者数据量没有大需要分库，使用自增id能节省存储空间并获得更好的性能

参考资料

UUIDs vs Auto-Incrementing Primary Keys in SQL
关于Mysql自增id的这些你可能还不知道
UUID的规范、v1-v5以及如何保证唯一性