为什么不推荐用 UUID 作为 Mysql 的主键

学习改变命运，技术铸就辉煌。

大家好，我是銘，全栈开发程序员。

UUID 是什么

我们先来了解一下 UUID 是什么？UUID 是指Universally Unique Identifier，翻译为中文是通用唯一识别码，UUID 的目的是让分布式系统中的所有元素都能有唯一的识别信息。如此一来，每个人都可以创建不与其它人冲突的 UUID，就不需考虑数据库创建时的名称重复问题。

UUID 的十六个八位字节被表示为 32个十六进制数字，以连字号分隔的五组来显示，形式为 8-4-4-4-12，总共有 36个字符（即三十二个英数字母和四个连字号）。例如：

123e4567-e89b-12d3-a456-426655440000

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

能否用 UUID 做主键

先说答案 ， 能，但是性能会比使用自增主键差一些，那原因是什么，我们具体分析：

我们平时建表的时候，一般都像下面这样，不会去使用 UUID，使用AUTO INCREMENT直接把主键 id 设置成自增，每次 +1

CREATE TABLE `user`(

`id` int NOT NULL AUTO INCREMENT COMMENT '主键',

`name` char(10) NOT NULL DEFAULT '' COMMENT '名字',

 PRIMARY KEY (`id`)

 )ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

那为什么把主键设置成自增呢， 我们在数据库保存数据的时候，就类似与下面的表格一样，这每一行数据，都是**保存在一个 16K 大小的页里 **。

每次都去遍历所有的行性能会不好，于是为了加速搜索，我们可以根据主键 id，从小到大排列这些行数据，将这些数据页用双向链表的形式组织起来，再将这些页里的部分信息提取出来放到一个新的 16kb 的数据页里，再加入层级的概念。于是，一个个数据页就被组织起来了，成为了一棵 B+ 树索引。

当我们在建表 sql 里面声明 AUTO INCREMENT 的时候，myqsl 的 innodb 引擎，就会为主键 id 生成一个主键索引，里面就是通过 B+ 树的形式来维护这套索引。

那么现在，我们需要关注两个点，

所以，由于数据页大小固定了 16k ，当我们需要插入一条数据的时候，数据页就会慢慢的被放满，当超过 16k 的时候，这个数据页就可能会进行分裂。

针对 B+ 树的叶子节点，如果主键是自增的，那么它产生的 id 每次都比前次要大，所以每次都会将数据家在 B+ 树的尾部，B+ 树的叶子节点本质是双向链表，查找它的首部和尾部，时间复杂度 O(1)，如果此时最末尾的数据也满了，那创建个新的页就好。

如果bb，上次 id=12111111，这次 id=343435455，那么为了让新加入数据后 B+ 树的叶子节点海涅那个保持有序，那么就需要旺叶子节点的中间找，查找的时间复杂度是 O(lgn)，如果这个页满了，那就需要进行页分裂，并且页分裂的操作是需要加悲观锁的。

所以，我们一般都建议把主键设置成自增，这样可以提高效率，提高性能。

那什么情况下不设置主键自增

mysql分库分表下的id

在分库分表的情况下，插入的 id 都是专门的 id 服务生成的，如果要严格按照自增的话，那么一般就会通过 redis 来生成，按批次去获得，比如一次性获取几百个，用完了再去获取，但是如果 redis 服务挂了，功能就完全没法用了，那有么有不依赖与第三方组件的方法呢？

有， 雪花算法

使用时间戳+机器码+流水号，一个字段实现了时间顺序、机器编码、创建时间。去中心化，方便排序，随便多表多库复制，并可抽取出生成时间，雪花ID主要是用在数据库集群上，去中心化，ID不会冲突又能相对排序。

总结

一般情况下，我们不推荐使用 UUID 来作为数据库的主键，只有分库分表的时候，才建议使用 UUID 来作为主键。