Mysql 优化-自增序列优化

---

几个T的资料等你来白嫖

---

自增序列

大家看到我之前发表
快速了解 B Tree ,B+Tree以及B+Mysql 中的作用
里面有提及自增序列的问题，我最近又花时间学习了一下 ：林晓斌老师 Mysql 实战 讲义 ，觉得里面说的挺好的，有兴趣小伙伴可以花点钱学习一下，本人将学习心得摘要整理一下，与大家分享。
很多小伙伴在开发过程中过度依赖于自增主键的连续性 设计业务模型架构，中途会遇到很多问题。

• 自增序列是不能保证连续性的

不能保证连续性有主要几个原因：

1. 唯一键插入过程中冲突导致自增序列增加。
2. 事务事务回滚
3. 复制表提前被申请使用

自增序列存储

1. MyISAM 引擎里面，自增值是被写在数据文件上的。
2. 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 时候用掉了