我是少侠露飞。学习塑造人生,技术扭转世界。
引言
我在之前一篇博客专门介绍了 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 外部 单点竞争
。