一、自增值保存在哪儿？
不同的引擎关于自增值的保存战略不同 A8站源码交易平台
1.MyISAM引擎的自增值保存在数据文件中
2.InnoDB引擎的自增值，在MySQL5.7及之前的版别，自增值保存在内存里，并没有耐久化。每次重启后，第一次翻开表的时分，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当时的自增值
select max(ai_col) from table_name for update;
在MySQL8.0版别，将自增值的改变记载在了redo log中，重启的时分依托redo log康复重启之前的值
二、自增值修正机制
假如字段id被界说为AUTO_INCREMENT，在刺进一行数据的时分，自增值的行为如下：
1.假如刺进数据时id字段指定为0、null或未指定值，那么就把这个表当时的AUTO_INCREMENT值填到自增字段
2.假如刺进数据时id字段指定了详细的值，就直接运用句子里指定的值
假定，某非必须刺进的值是X，当时的自增值是Y
1.假如X<y，那么这个表的自增值不变
2.假如X>=Y，就需要把当时自增值修正为新的自增值
新的自增值生成算法是：从auto_increment_offset（初始值）开端，以auto_increment_increment（步长）为步长，持续叠加，直到找到第一个大于X的值，作为新的自增值
三、自增值的修正机遇
创立一个表t，其间id是自增主键字段、c是仅有索引，建表句子如下：
CREATE TABLE `t` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `c` (`c`)
) ENGINE=InnoDB;
假定，表t里边现已有了(1,1,1)这条记载，这时再履行一条刺进数据指令：
insert into t values(null, 1, 1);
履行流程如下：
1.履行器调用InnoDB引擎接口写入一行，传入的这一行的值是(0,1,1)
2.InnoDB发现用于没有指定自增id的值，获取表t当时的自增值2
3.将传入的行的值改成(2,1,1)
4.将表的自增值改成3
5.持续履行刺进数据操作，因为现已存在c=1的记载，所以报Duplicate key error（仅有键抵触），句子回来
对应的履行流程图如下：
在这之后，再刺进新的数据行时，拿到的自增id便是3。呈现了自增主键不接连的状况
仅有键抵触和业务回滚都会导致自增主键id不接连的状况
四、自增锁的优化
自增id锁并不是一个业务锁，而是每次请求完就立刻开释，以便答应其他业务再请求 A8站源码交易平台
但在MySQL5.0版其他时分，自增锁的规模是句子等级。也便是说，假如一个句子请求了一个表自增锁，这个锁会等句子履行完毕今后才开释
MySQL5.1.22版别引入了一个新战略，新增参数innodb_autoinc_lock_mode，默认值是1
1.这个参数设置为0，表明选用之前MySQL5.0版其他战略，即句子履行完毕后才开释锁
2.这个参数设置为1
一般insert句子，自增锁在请求之后就立刻开释
相似insert … select这样的批量刺进数据的句子，自增锁仍是要等句子完毕后才被开释
3.这个参数设置为2，一切的请求自增主键的动作都是请求后就开释锁
为了数据的一致性，默认设置为1
假如sessionB请求了自增值今后立刻就开释自增锁，那么就可能呈现这样的状况：
sessionB先刺进了两行数据(1,1,1)、(2,2,2)
sessionA来请求自增id得到id=3，刺进了(3,5,5)
之后，sessionB持续履行，刺进两条记载(4,3,3)、(5,4,4)
当binlog_format=statement的时分，两个session是一起履行刺进数据指令的，所以binlog里边对表t2的更新日志只要两种状况：要么先记sessionA的，要么先记载sessionB的。无论是哪一种，这个binlog拿到从库履行，或许用来康复暂时实例，备库和暂时实例里边，sessionB这个句子履行出来，生成的成果里边，id都是接连的。这时，这个库就发生了数据不一致 A8站源码交易平台
处理这个问题的思路：
1）让原库的批量刺进数据句子，固定生成接连的id值。所以，自增锁直到句子履行完毕才开释，便是为了到达这个意图
2）在binlog里边把刺进数据的操作都照实记载进来，到备库履行的时分，不再依赖于自增主键去生成。也便是把innodb_autoinc_lock_mode设置为2，一起binlog_format设置为row
假如有批量刺进数据（insert … select、replace … select和load data）的场景时，从并发刺进数据功能的视点考虑，主张把innodb_autoinc_lock_mode设置为2，一起binlog_format设置为row，这样做既能并发性，又不会呈现数据一致性的问题
关于批量刺进数据的句子，MySQL有一个批量请求自增id的战略：
1.句子履行过程中，第一次请求自增id，会分配1个
2.1个用完今后，这个句子第2次请求自增id，会分配2个
3.2个用完今后，仍是这个句子，第三次请求自增id，会分配4个
4.顺次类推，同一个句子去请求自增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);
create table t2 like t;
insert into t2(c,d) select c,d from t;
insert into t2 values(null, 5,5);
insert … select，实际上往表t2中刺进了4行数据。可是，这四行数据是分三次请求的自增id，第一次请求到了id=1，第2次被分配了id=2和id=3，第三次被分配到id=4到id=7
因为这条句子实际上只用上了4个id，所以id=5到id=7就被糟蹋掉了。之后，再履行insert into t2 values(null, 5,5)，实际上刺进了的数据便是(8,5,5)
<y，那么这个表的自增值不变
<y，那么这个表的自增值不变
这是主键id呈现自增id不接连的第三种原因<y，那么这个表的自增值不变
