现在大部分软件开发都离不开数据库。Mysql也是经常使用的数据库。mysql数据库有一个主键生成规则，是自增量的。也是我们经常用的。本文将对此进行介绍。
:
目录
1.自我增值储存在哪里？二。自我增值修改机制。自我增值改装机会四。自增量锁优化v .自增量主键用完。
一、自增值保存在哪儿？
不同的引擎对于自我增量有不同的节省策略。
1.1的自增量。MyISAM引擎保存在数据文件中。
2.InnoDB引擎的自增量，在MySQL5.7及之前的版本中，自增量是存储在内存中的，并不是持久的。每次重启后，第一次打开该表时，会找到自增量max(id)的最大值，然后将max(id)步长作为该表的当前自增量。
select max(ai _ col)from table _ name for update；
在MySQL8.0版本中，增值的变化被记录在重做日志中，重启前的值被重做日志恢复。
二、自增值修改机制
如果字段id定义为AUTO_INCREMENT，则在插入一行数据时，自增量的行为如下：
1.如果在插入数据时将id字段指定为0、null或未指定，则将此表的当前AUTO_INCREMENT值填充到自动增量字段中。
2.如果在插入数据时在id字段中指定了特定值，则直接使用语句中指定的值。
假设二次插入的值是X，当前自增量是y。
1.如果XY，那么这个表的自增量不变。
2.如果X=Y，则需要将当前自增量修改为新的自增量。
新的自增值生成算法是：从auto_increment_offset（初始值）开始，以auto_increment_increment（步长）为步长，持续叠加，直到找到第一个大于X的值，作为新的自增值
三、自增值的修改时机
创建一个表T，其中id是自增主键字段，C是唯一索引。创建表的语句如下：
创建表` t `(
` id ' int(11)NOT NULL AUTO _ INCREMENT，
` c ' int(11)默认为空，
` d` int(11)默认为空，
主键(` id `)，
唯一键“c”(“c ”)
)ENGINE=InnoDB
假设在表T中已经有一个记录(1，1，1)，那么执行一个插入数据命令：
插入t值(null，1，1)；
执行过程如下：
1.执行器调用InnoDB引擎接口写一行，传入行的值是(0，1，1)
2.InnoDB找到没有指定自动增量id的值，并获得表t的当前自动增量2。
3.将引入线的值更改为(2，1，1)
4.将表格的自增量更改为3。
5.继续插入数据。由于c=1的记录已经存在，它被报告为重复键错误，并且语句返回。
相应的执行流程图如下：
此后，当插入新数据行时，自动增量id为3。出现自增主键的不连续。
唯一键冲突和事务回滚都会导致自增主键id不连续的情况
四、自增锁的优化
自增量id锁不是事务锁，而是在每次申请后立即释放，以便允许其他事务再次申请。
但是在MySQL5.0版本中，自增锁的范围是语句级的。也就是说，如果一条语句申请了一个表自增量锁，那么直到该语句被执行，锁才会被释放。
MySQL版本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时，两个会话同时执行插入数据的命令，所以在binlog中更新表t2的日志只有两种情况：要么先记录sessionA，要么先记录sessionB。无论哪种方式，这个binlog都是从库中执行的，或者用于恢复临时实例、备份库和临时实例。当执行语句sessionB时，生成的结果中的id是连续的。此时，此库中出现数据不一致。
解决这个问题的思路：
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，会分配一个。
2.1用完之后，本声明第二次申请自增id，2将被分配。
3.2用完之后，也是这个说法。第三次申请自增id，分配4个。
4.以此类推，同样的语句适用于自增id，每次申请的自增id数量是上一次的两倍。
插入t值(null，1，1)；
插入t值(null，2，2)；
插入t值(null，3，3)；
插入t值(null，4，4)；
像t一样创建表T2；
插入t2(c，d)从t中选择c，d；
插入t2值(null，5，5)；
Insert … select，它实际上将4行数据插入到表t2中。不过这四行数据都是分三次申请的自增id。第一个应用程序的id=1，第二个应用程序的id=2和id=3，第三个应用程序的id=4至id=7。
由于这个语句实际上只使用了4个id，所以id=5到id=7都被浪费了。然后，执行insert into t2 values(null，5，5)，实际插入的数据是(8，5，5)。
这是主键id出现自增id不连续的第三种原因
五、自增主键用完了
如果在将主键字段添加到已定义类型的上限后插入一行记录，将会报告主键冲突错误。
以无符号整数(4字节，上限为2 ^ 32 ^ 1 ^ 2 { 32 }-1 ^ 2321)为例，用下面的语句序列进行验证：
创建表t ( id INT UNSIGNED auto_increment主键)auto _ increment=4294967295
插入t值(NULL)；
插入t值(NULL)；
第一条insert语句成功插入数据后，该表的AUTO_INCREMENT没有变化(仍然是4294967295)，导致第二条insert语句获得相同的自增id值，然后试图执行insert语句，报告主键冲突错误。
推荐资料:
https://time.geekbang.org/column/article/80531
本文关于MySQL自增主键实现的详细讲解到此为止。关于MySQL自增主键的更多信息，请搜索我们之前的文章或者继续浏览下面的相关文章。希望大家以后能多多支持我们！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。