自增序列
大家看到我之前发表
快速了解 B Tree ,B+Tree以及B+Mysql 中的作用
里面有提及自增序列的问题,我最近又花时间学习了一下 :林晓斌老师 Mysql 实战 讲义 ,觉得里面说的挺好的,有兴趣小伙伴可以花点钱学习一下,本人将学习心得摘要整理一下,与大家分享。
很多小伙伴在开发过程中过度依赖于自增主键的连续性 设计业务模型架构,中途会遇到很多问题。
- 自增序列是不能保证连续性的
不能保证连续性有主要几个原因:
- 唯一键插入过程中冲突导致自增序列增加。
- 事务事务回滚
- 复制表提前被申请使用
自增序列存储
-
MyISAM 引擎里面,自增值是被写在数据文件上的。
-
InnoDB 中,自增值是被记录在内存的。MySQL 直到 8.0 版本,才给 InnoDB 表的自增值加上了持久化的能力,确保重启前后一个表的自增值不变。
自增序列不能被退回的
在 MySQL 5.0 版本的时候,自增锁的范围是语句级别。
也就是说,如果一个语句申请了一个表自增锁,这个锁会等语句执行结束以后才释放。
显然,这样设计会影响并发度。
MySQL 5.1.22 版本引入了一个新策略,新增参数 innodb_autoinc_lock_mode,默认值是 1。这个参数的值被设置为 0 时,表示采用之前 MySQL 5.0 版本的策略,即语句执行结束后才释放锁;
innodb_autoinc_lock_mode:
- 这个参数的值被设置为 1 时:普通 insert 语句,自增锁在申请之后就马上释放;类似 insert … select
这样的批量插入数据的语句,自增锁还是要等语句结束后才被释放; - 这个参数的值被设置为 2 时,所有的申请自增主键的动作都是申请后就释放锁。
自增序列Id 申请问题
正常情况下:
创建一个申请一个
insert into t values(null, 1,1);
但是如果是批量插入的时候语句
select … insert
Mysql 不是一个一个申请分配资源,而是有自己优化策略:
同一个语句去申请自增 id,每次申请到的自增 id 个数都是上一次的两倍
简单说一下第三中情况:
insert into t values(null, 1,1);
insert into t values(null, 2,2);
insert into t values(null, 3,3);
insert into t values(null, 4,4); 当前自增序列是4
//创建表结构时候,提前申请 5~7
create table t2 like t;insert into t2(c,d) select c,d from t;
insert into t2 values(null, 5,5); 自增序列是8
创建表t2 时候用掉了