欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

我为什么不建议开发中使用UUID作为MySQL的主键

程序员文章站 2022-05-08 15:00:00
...

我是少侠露飞。学习塑造人生,技术改变世界。

引言

我在之前一篇博客专门介绍了MySQL聚簇索引和非聚簇索引,附传送门:
【享学MySQL】系列:MySQL索引的数据结构,索引种类及聚簇索引和非聚簇索引
简单来说,就是我们设计表的时候,基本都会人为设定一个主键,这就是聚簇索引(如果没有设定主键,MySQL会选择非空不唯一的字段作为聚簇索引,如果依然没有,则MySQL会选择自己隐藏列row_id作为聚簇索引)。
MySQL主键分为自增主键UUID两种形式。今天我们就针对这个主键的生成深入探究一下。

自增主键和UUID比较

首先需要明确一点,自增主键是整数,UUID是字符串类型(一般为36位)。

所以UUID相比自增主键一个首要的缺点就是UUID主键索引占据空间更大

其次我们再来分别来看看两种主键生成方式插入数据时发生的情况。

自增主键的插入:

我为什么不建议开发中使用UUID作为MySQL的主键
如上图所示,InnoDB把每条记录都保存在前一条记录的后面,因为主键的值是顺序的。当达到页面最大的填充因子(Fill Factor)(InnoDB初始的填充因子是15/16),后一条记录就会写入新页面。

UUID主键的插入

我为什么不建议开发中使用UUID作为MySQL的主键
由于新行的主键不一定比前一个大,因此InnoDB不能总是把新行插入到索引的最后。它不得不为新行寻找合适的位置:通常在已有数据的中段,并且为它分配空间。这会导致大量的额外工作并且导致不优化的数据布局。主要缺点如下:

  • 目标页面也许会被刷写到磁盘上并且从缓存中移走,无论哪种情况,InnoDB都不得不在插入新行之前从磁盘上找到并读取它,这导致了大量的随机I/O。
  • InnoDB有时不得不进行分页,为新行开辟空间。这会导致移动大量数据。
  • 页面会因为分页而变得稀疏和不规则地被填充,因此最终的数据会有碎片。

因此通过UUID的方式插入数据花费的时间也更长。

MySQL自增主键的实现

自增锁的值保存位置

InnoDB引擎的自增值,在MySQL5.7及之前的版本,自增值保存在内存里,并没有持久化。每次重启后,第一次打开表的时候,都会去找自增值的最大值max(id),然后将max(id)+步长作为这个表当前的自增值

select max(id) from table_name for update;

在MySQL8.0版本,将自增值的变更记录在了redo log中,重启的时候依靠redo log恢复重启之前的值。

自增锁的实现

自增id锁并不是一个事务锁,而是每次申请完就马上释放,以便允许别的事务再申请。

但在MySQL5.0版本的时候,自增锁的范围是语句级别。也就是说,如果一个语句申请了一个表自增锁,这个锁会等语句执行结束以后才释放

MySQL5.1.22版本引入了一个新策略,新增参数innodb_autoinc_lock_mode,默认值是1

1.这个参数设置为0,表示采用之前MySQL5.0版本的策略,即语句执行结束后才释放锁。

2.这个参数设置为1。

  • 普通insert语句,自增锁在申请之后就马上释放 。
  • 类似insert … select这样的批量插入数据的语句,自增锁还是要等语句结束后才被释放。

3.这个参数设置为2,所有的申请自增主键的动作都是申请后就释放锁。

所以当发生主键冲突和事务回滚都会导致自增主键id不连续的情况。

思考

事实上开发中基本采用自增主键的方式。但是主键顺序一定是不会造成坏的结果么?
答案当然是否定的。
自增主键为了防止多个线程返回同样的主键,生成主键的过程必然是要加自增锁的,但是在高并发的场景下,冲突的概率就大大提高了,并发插入很可能会竞争下一个自增锁,即会带来InnoDB内部单点竞争