InnoDB
经过 MVCC
和 NEXT-KEY Locks
,解决了在可重复读
的事务隔离级别下出现幻读
的问题。MVCC
我先挖个坑,往后再细讲,这篇文章咱们主要来谈谈那些可爱的锁。算法
幻读是在可重复读
的事务隔离级别下会出现的一种问题,简单来讲,可重复读
保证了当前事务不会读取到其余事务已提交的 UPDATE
操做。但同时,也会致使当前事务没法感知到来自其余事务中的 INSERT
或 DELETE
操做,这就是幻读
。sql
行锁在 InnoDB 中是基于索引
实现的,因此一旦某个加锁操做没有使用索引,那么该锁就会退化为表锁
。spa
顾名思义,记录锁就是为某行记录加锁,它封锁该行的索引记录
:code
-- id 列为主键列或惟一索引列
SELECT * FROM table WHERE id = 1 FOR UPDATE;
复制代码
id 为 1 的记录行会被锁住。索引
须要注意的是:id
列必须为惟一索引列
或主键列
,不然上述语句加的锁就会变成临键锁
。事务
同时查询语句必须为精准匹配
(=
),不能为 >
、<
、like
等,不然也会退化成临键锁
(感谢评论区 @decodes 提醒)。string
在经过 主键索引
与 惟一索引
对数据行进行 UPDATE 操做时,也会对该行数据加记录锁
:table
-- id 列为主键列或惟一索引列
UPDATE SET age = 50 WHERE id = 1;
复制代码
间隙锁基于非惟一索引
,它锁定一段范围内的索引记录
。间隙锁基于下面将会提到的Next-Key Locking
算法,请务必牢记:使用间隙锁锁住的是一个区间,而不单单是这个区间中的每一条数据。class
SELECT * FROM table WHERE id BETWEN 1 AND 10 FOR UPDATE;
复制代码
即全部在(1,10)
区间内的记录行都会被锁住,全部id 为 二、三、四、五、六、七、八、9 的数据行的插入会被阻塞,可是 1 和 10 两条记录行并不会被锁住。im
除了手动加锁外,在执行完某些 SQL 后,InnoDB 也会自动加间隙锁,这个咱们在下面会提到。
Next-Key 能够理解为一种特殊的间隙锁,也能够理解为一种特殊的算法。经过临建锁能够解决幻读
的问题。 每一个数据行上的非惟一索引列
上都会存在一把临键锁,当某个事务持有该数据行的临键锁时,会锁住一段左开右闭区间的数据。须要强调的一点是,InnoDB
中行级锁
是基于索引实现的,临键锁只与非惟一索引列
有关,在惟一索引列
(包括主键列
)上不存在临键锁。
假设有以下表:
MySql,InnoDB,Repeatable-Read:table(id PK, age KEY, name)
id | age | name |
---|---|---|
1 | 10 | Lee |
3 | 24 | Soraka |
5 | 32 | Zed |
7 | 45 | Talon |
该表中 age
列潜在的临键锁
有:
(-∞, 10],
(10, 24],
(24, 32],
(32, 45],
(45, +∞],
在事务 A
中执行以下命令:
-- 根据非惟一索引列 UPDATE 某条记录
UPDATE table SET name = Vladimir WHERE age = 24;
-- 或根据非惟一索引列 锁住某条记录
SELECT * FROM table WHERE age = 24 FOR UPDATE;
复制代码
无论执行了上述 SQL 中的哪一句,以后若是在事务 B
中执行如下命令,则该命令会被阻塞:
INSERT INTO table VALUES(100, 26, 'Ezreal');
复制代码
很明显,事务 A
在对 age
为 24 的列进行 UPDATE 操做的同时,也获取了 (24, 32]
这个区间内的临键锁。
不只如此,在执行如下 SQL 时,也会陷入阻塞等待:
INSERT INTO table VALUES(100, 30, 'Ezreal');
复制代码
那最终咱们就能够得知,在根据非惟一索引
对记录行进行 UPDATE \ FOR UPDATE \ LOCK IN SHARE MODE
操做时,InnoDB 会获取该记录行的 临键锁
,并同时获取该记录行下一个区间的间隙锁
。
即事务 A
在执行了上述的 SQL 后,最终被锁住的记录区间为 (10, 32)
。
行锁
的实现依赖于索引
,一旦某个加锁操做没有使用到索引,那么该锁就会退化为表锁
。主键索引
在内的惟一索引
中,锁定单条索引记录。非惟一索引
中,锁定开区间
范围内的一段间隔,它是基于临键锁实现的。非惟一索引
中,该类型的每条记录的索引上都存在这种锁,它是一种特殊的间隙锁,锁定一段左开右闭
的索引区间。