Mysql 优化-自增序列优化

自增序列

大家看到我之前发表 快速了解 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 时候用掉了