以前的文章内容把 InnoDB 中的全部的锁都详细介绍了一下，包含意向锁、纪录锁...自增锁吧啦吧啦的。可是后边自己转过头去看看的情况下发觉，对自增锁的详细介绍竟然才短短一段。

实际上自增锁（AUTO-INC Locks）这方面或是有很多非常值得探讨的关键点，比如在高并发的情景下，InnoDB 是怎样确保该值恰当的开展自增的，此章就专业来简易讨论一下 InnoDB 中的自增锁。

什么叫自增锁

以前大家提及过，自增锁是一种较为独特的表级锁。而且在事务管理向包括了 AUTO_INCREMENT 列的表中增加数据信息时便会去拥有自增锁，假定事务管理 A 已经做这一实际操作，假如另一个事务管理 B 试着实行 INSERT句子，事务管理 B 会被阻塞住，直至事务管理 A 释放出来自增锁。

这怎么讲，说他对，可是他都不彻底对。

个人行为与限定

实际上上边说的那类堵塞状况仅仅自增锁个人行为的在其中一种，能够了解为自增锁便是一个插口，其实际的完成有多种多样。实际的配备项为 innodb_autoinc_lock_mode ，根据这一配备项我们可以更改自增锁中运作的一些关键点。

而且，自增锁还有一个限定，那便是被设定为 AUTO_INCREMENT 的列务必是数据库索引，或是该列是数据库索引的一部分（联合索引），但是这一限定针对绝大多数开发设计情景下并没什么危害。

终究大家的基操不便是把 id 设定为 AUTO_INCREMENT 吗。

锁方式

实际上在 InnoDB 中，把锁的个人行为称为锁方式很有可能更为精确，那实际有什么锁方式呢，以下：

• 模式（Traditional）
• 持续方式（Consecutive）
• 交叉式方式（Interleaved）

各自相匹配配备项 innodb_autoinc_lock_mode 的值0、1、2.

见到这就早已了解为什么上边说不精确了，由于三种方式下，InnoDB 对高并发的解决是不一样的，并且实际挑选哪一种锁方式跟你当今应用的 MySQL 版本号也有关联。

在 MySQL 8.0 以前，InnoDB 锁方式默认设置为持续方式，数值1，而在 MySQL 8.0 以后，默认设置方式变成了交叉式方式。对于为什么会更改默认设置方式，后边会讲。

模式

模式（Traditional），简言之便是都还没锁方式这一定义时，InnoDB 的自增锁运作的方式。仅仅后边版本升级，InnoDB 引进了锁方式的定义，随后 InnoDB 给了这类之前默认设置的方式一个名称，叫——模式。

模式实际是咋工作中的？

我们知道，在我们向包括了 AUTO_INCREMENT 列的表中插进数据信息时，都是会拥有那么一个独特的表锁——自增锁（AUTO-INC），而且当句子实行完以后便会释放出来。这样一来能够确保单独句子内转化成的自升值是持续的。

这样一来，模式的缺点就当然曝露出来，如果有好几个事务管理高并发的实行 INSERT 实际操作，AUTO-INC的存有会促使 MySQL 的特性略微降低，由于另外只有实行一条 INSERT 句子。

持续方式

持续方式（Consecutive）是 MySQL 8.0 以前默认设置的方式，往往明确提出这类方式，是由于模式存有危害特性的缺点，因此才拥有持续方式。

在锁方式处在持续方式下时，假如 INSERT 句子可以提早明确插进的信息量，则能够无需获得自增锁，举个事例，像 INSERT INTO 这类简易的、能提早确定总数的增加句子，就不容易应用自增锁，这一非常好了解，在自升值上，我能立即把这个 INSERT 句子所必须的室内空间流出去，就可以执行下一个句子了。

可是假如 INSERT 句子不可以提早确定信息量，则依然会去获得自增锁。比如像 INSERT INTO ... SELECT ... 这类句子，INSERT 的值来自另一个 SELECT 句子。

持续方式的图和交叉式方式类似

交叉式方式

交叉式方式（Interleaved）下，全部的 INSERT 句子，包括 INSERT 和 INSERT INTO ... SELECT ，都不容易应用 AUTO-INC 自增锁，只是应用比较轻巧的 mutex 锁。这样一来，好几条 INSERT 句子能够高并发的实行，这也是三种锁方式中扩展性最好是的一种。

高并发实行所产生的不良反应便是单独 INSERT 的自升值并不持续，由于 AUTO_INCREMENT 的值分派会在好几个 INSERT 句子中往返交叉式的实行。

优势很确立，缺陷是在高并发的状况下没法确保数据一致性，这一下边会探讨。

交叉式方式缺点

要掌握缺点是啥，还得先了解一下 MySQL 的 Binlog。Binlog 一般用以 MySQL 的数据信息拷贝，简单一点便是用以主从关系同歩。在 MySQL 中 Binlog 的文件格式有 3 种，分别是：

• Statement 根据句子，只纪录对数据信息干了改动的SQL句子，可以合理的降低binlog的信息量，提升 载入、根据binlog播放的特性
• Row 只纪录被改动的行，因此Row纪录的binlog日志量一般来说会比Statement文件格式要多。根据Row的binlog日志十分详细、清楚，纪录了全部数据信息的变化，可是缺陷是很有可能会十分多，比如一条update句子，有可能是全部的数据信息都是有改动；再比如alter table这类的，改动了某一字段名，一样的一条纪录都是有修改。
• Mixed Statement和Row的融合，如何个结合法呢。比如像alter table这类的对表构造的改动，选用Statement文件格式。其他的对数据信息的改动比如update和delete选用Row文件格式开展纪录。

假如 MySQL 选用的文件格式为 Statement ，那麼 MySQL 的主从关系同歩事实上同歩的便是一条一条的 SQL 句子。假如这时大家选用了交叉式方式，那麼高并发状况下 INSERT 句子的实行次序就没法获得确保。

很有可能你要没看得出难题在哪里，INSERT 另外交叉式实行，而且 AUTO_INCREMENT 交叉式分派可能立即造成主从关系中间同行业的数据信息外键约束 ID 不一样。而这对主从关系同歩而言是毁灭性的。

也就是说，假如你的 DB 有主从关系同歩，而且 Binlog 储存文件格式为 Statement，那麼不必将 InnoDB 自增锁方式设定为交叉式方式，会有什么问题。实际上主从关系同歩的全过程远比图中中的繁杂，以前因为我读过详尽的MySQL主从关系同歩的文章内容，有兴趣能够先看一看。

而之后，MySQL 将日志储存文件格式从 Statement 变成了 Row，这样一来，主从关系中间同歩的便是真正的行数据信息了，并且 外键约束ID 在同歩到从库以前早已明确了，就对同歩句子的次序并不比较敏感，就避开了上边 Statement 的难题。

根据 MySQL 默认设置 Binlog 文件格式从 Statement 到 Row 的变动，InnoDB 也将其自增锁的默认设置完成从持续方式，拆换到高效率高些的交叉式方式。

鱼与熊掌

可是假如你的 MySQL 版本号依然默认设置应用持续方式，但另外又要想提升 特性，应该怎么办呢？这一实际上得做一些选择。

假如你能判断你的系统软件事后不容易应用 Binlog，那麼你能挑选将自增锁的锁方式从持续方式改成交叉式方式，那样能够提升 MySQL 的高并发。而且，没了主从关系同歩，INSERT 句子在从库乱序执行造成的 AUTO_INCREMENT 值不配对的难题也就当然不容易碰到了。

汇总

你很有可能要说，为什么要掌握那么深？有啥用？

实际上还真有，比如在业务流程中你有一个必须实行 几十秒 的脚本制作，脚本制作中不断的启用数次 INSERT，这时候就问这个难题，在这里几十秒里，会堵塞别的的客户应用相匹配的作用吗？

假如你对自增锁有充足的掌握，那麼这个问题可能得到解决。

好啦之上便是这篇blog的所有内容了，热烈欢迎搜索微信关心【SH的全栈开发手记】，回应【序列】获得MQ学习材料，包括基本定义分析和RocketMQ详尽的源代码分析，不断升级中。

如果你觉得本文对您有协助，还不便点个赞，关个注，分出享，留个言。