mysql uuid主键 分页_关于mysql:我为什么不建议开发中使用UUID作为MySQL的主键

我是少侠露飞。学习塑造人生，技术扭转世界。

引言

我在之前一篇博客专门介绍了MySQL聚簇索引和非聚簇索引，附传送门：

【享学MySQL】系列：MySQL索引的数据结构，索引品种及聚簇索引和非聚簇索引

简略来说，就是咱们设计表的时候，根本都会人为设定一个主键，这就是聚簇索引(如果没有设定主键，MySQL会抉择非空不惟一的字段作为聚簇索引，如果仍然没有，则MySQL会抉择本人暗藏列row_id作为聚簇索引)。

MySQL主键分为自增主键和UUID两种模式。明天咱们就针对这个主键的生成深刻探索一下。

自增主键和UUID比拟

首先须要明确一点，自增主键是整数，UUID是字符串类型(个别为36位)。

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

其次咱们再来别离来看看两种主键生成形式插入数据时产生的状况。

自增主键的插入：

如上图所示，InnoDB把每条记录都保留在前一条记录的前面，因为主键的值是程序的。当达到页面最大的填充因子(Fill Factor)(InnoDB初始的填充因子是15/16)，后一条记录就会写入新页面。

UUID主键的插入

因为新行的主键不肯定比前一个大，因而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外部单点竞争。