InnoDB自增锁解析：MySQL表锁真相与优化策略

时间：2025-12-16 19:52

自增锁是一种特殊的表级别锁（table-level lock），专门针对事务插入AUTO_INCREMENT类型的列。今天介绍InnoDB七种锁的第一种：自增锁(Auto-inc Locks)。一

自增锁（Auto-inc Locks）是一种特殊的表级锁，专门用于处理向含有AUTO_INCREMENT列的表插入数据的事务。

今天我们将深入探讨InnoDB七种锁类型中的第一种：自增锁。

一、案例场景分析

在MySQL的InnoDB引擎中，使用默认的重复读（RR）隔离级别，假设我们有一张数据表：

t(id AUTO_INCREMENT, name);

表中已有的数据为：

1, shenjian
2, zhangsan
3, lisi

事务A首先执行一条插入语句，但还未提交：

insert into t(name) values(xxx);

随后，事务B也执行一条插入：

insert into t(name) values(ooo);

问题来了：事务B会被阻塞住吗？

二、案例原理剖析

我们知道，InnoDB在RR隔离级别下通过多版本并发控制解决了幻读问题。但在上述场景中：

(1) 事务A先执行insert操作，会生成一条(4, xxx)的记录。因为是自增列，我们无需显式指定id为4，InnoDB会自动递增生成。请注意，此时事务尚未提交。

(2) 接着事务B执行insert操作。假设它不会被阻塞，则会生成一条(5, ooo)的记录。

乍一看这似乎没什么问题。但接下来，

(3) 如果事务A继续插入一条数据：

insert into t(name) values(xxoo);

此时会生成一条(6, xxoo)的记录。

(4) 随后，事务A执行一条查询：

select * from t where id>3;

得到的结果集将是：

4, xxx
6, xxoo

这里出现了奇怪的现象：查询结果中竟然无法查看到id为5的记录。在RR隔离级别下，确实不应该读取到未提交事务所生成的数据。

但这对事务A来说就变得很诡异了：对于一个自增列，事务A连续插入了两条记录，第一条id是4，紧接着的一条却变成了6，中间仿佛凭空消失了一个id值，就像遇到了神秘的“幻影”。

三、自增锁的机制

自增锁正是为了解决这个问题而设计的。它是一种特殊的表级锁，专门控制在具有AUTO_INCREMENT列的表中进行插入操作的事务。在最简单的情况下，如果一个事务正在向表中插入记录，那么所有其他试图插入的事务都必须等待，以确保第一个事务插入的行能够获得连续的主键值。

正如MySQL官方文档所解释的那样：

An AUTO-INC lock is a special table-level lock taken by transactions inserting into tables with AUTO_INCREMENT columns. In the simplest case, if one transaction is inserting values into the table, any other transactions must wait to do their own inserts into that table, so that rows inserted by the first transaction receive consecutive primary key values.

与此同时，InnoDB提供了`innodb_autoinc_lock_mode`配置参数，允许我们调整和改变这种锁的模式与具体行为。