最近在使用数据库要建表选择主键的时候，突然想到经常使用的两类主键id——自增id和UUID有什么区别，用那种更好？之前使用MySql的时候通常直接就选择了自增id了，工作的时候也看到有些项目使用UUID做主键，但是都没怎么考虑两者的区别，优缺点之类的。现在要键新表选择主键的时候，就需要考虑选择哪种做主键了，因此就有了这篇
本文首先分别简单为什么数据库需要主键，然后介绍自增id和UUID，接着比较两者的区别，最后给出何时使用哪种类型做主键更好。
在关系型数据库模型中，关系型数据库是一组具有很多行数据的表组成的，这些不同的表之间通过关联起来，包括主键和外键。
主键用来唯一标识出在一张表中的某一条数据，在数据库中设置了主键约束的列数据库引擎会保证其唯一性。外键则是在另外的表中存储的其他表的主键的列。通过主键和外键就可以将数据库中不同的表关联起来。
为了应对业务场景的变化，通常将主键的值设置为与业务无关的量，也就是本文所讨论的自增id和UUID。
简单总结一下就是为了唯一标识表中的一行数据需要主键，为了使多个表关联起来需要使用外键，为了与业务解耦，需要采用与业务无关的值作为主键。
自增ID简单的说就是在向表中插入一条数据时不用自己设置id的值，数据库引擎会自动根据表中的数据的id+1进行填充。
由于是数据库引擎负责生成的主键id，因此不需要我们自己处理主键重复的问题，同时生成比较简单，速度快，并且因为是增量生成的，在插入和查找数据的时候可以比使用随机的值具有更好的性能。
以MySQL为例，数据存储在主索引（B+树）的叶子节点上，因此同一叶子节点的各条数据继续需要按主键顺序进行存储，当由一条新的数据插入的时候，如果向新数据的主键处于已有数据主键的中间值，可能需要为了将新数据插入到对应的位置而移动数据，会增加额外的开销。
同时由于id是根据插入的顺序递增的，对开发人员来说，在某种程度上会比使用近乎随机值的UUID更加直观。而且相比UUID需要128位进行存储，自增id通常仅需要使用64位的无符号整型(0,)就可以满足绝大部分的场景需求。
UUID——通用唯一标识码（Universally Unique Identifier）
UUID最早由Apollo Computers在1990年提出，随后由OSF（Open Software Foundation）标准化。UUID有128位组成，通常表示为32个16进制数。
这里简单说一些各个版本的区别：
- UUID v1 基于时间戳和MAC地址生成，但时间精度不足时使用clock sequence来扩展时间戳。由于此版本依赖于设备供应商提供唯一的MAC地址，因此可以通常它反查到对应的MAC地址
- UUID v2 没有提供实现细节，基本很少使用
- UUID v3,v5 都是通过hash namespace的标识符和名称生成的，不同在于v3使用MD5作为hash函数，v5使用SHA-2做hash函数。当输入的namespace与参数相同时会输出相同的UUID。
- UUID v4 除了4位表示版本和2-3位标识varant外，其余位全部随机。这是用得最广泛的版本
五个版本都可以保证唯一，但是不管是那个版本生成的UUID，对数据库而已生成的UUID值都近乎随机。
- 自增ID是有序的，而UUID是随机的。前面已经说了，如果主键是有序的，数据库可以具有更好的性能（至少对MySQL而已是如此）
- 自增ID所需的存储空间比UUID要小
- 由于自增ID比UUID更加简单，因此生成自增ID的生成速度也比UUID更快
- 自增ID与数据相关，主键会暴露出去的话，自增ID会显示当前表中的数据规模；而UUID则无此风险
- 自增ID在不同的数据库中可能重复，在分布式的环境下无法保证唯一。而UUID在分布式环境下也可以保证唯一
具体而已，自增ID在性能上更有优势，而UUID则更加适应分布式场景
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/184894.html