InnoDB的锁机制浅析(四)—不同SQL的加锁状况

不同SQL的加锁状况

文章总共分为五个部分：

• InnoDB的锁机制浅析(一)—基本概念/兼容矩阵
• InnoDB的锁机制浅析(二)—探索InnoDB中的锁(Record锁/Gap锁/Next-key锁/插入意向锁)
• InnoDB的锁机制浅析(三)—幻读
• InnoDB的锁机制浅析(四)—不同SQL的加锁状况
• InnoDB的锁机制浅析(五)—死锁场景(Insert死锁)

大而全版（五合一）：InnoDB的锁机制浅析(All in One)

前言

如果一个SQL语句要对二级索引(非主键索引)设置X模式的Record锁，InnoDB还会检索出相应的聚簇索引(主键索引)并对它们设置锁定。

1 SELECT ... FROM...不加锁

SELECT ... FROM是快照读取，除了SERIALIZABLE的事务隔离级别，该SQL语句执行时不会加任何锁。

SERIALIZABLE级别下，SELECT语句的执行会在遇到的索引记录上设置S模式的next-key锁。但是对于唯一索引，只锁定索引记录，而不会锁定gap。

2 UPDATE系列

S锁读取(SELECT ... LOCK IN SHARE MODE)，X锁读取(SELECT ... FOR UPDATE)、更新UPDATE和删除DELETE这四类语句，采用的锁取决于搜索条件中使用的索引类型。

• 如果使用唯一索引，InnoDB仅锁定索引记录本身，不锁定间隙。
• 如果使用非唯一索引，或者未命中索引，InnoDB使用间隙锁或者next-key锁来锁定索引范围，这样就可以阻止其他事务插入锁定范围。

2.1 UPDATE语句

UPDATE ... WHERE ...在搜索遇到的每条记录上设置一个独占的next-key锁，如果是唯一索引只锁定记录。
当UPDATE修改聚簇索引时，将对受影响的二级索引采用隐式锁，隐式锁是在索引中对二级索引的记录逻辑加锁，实际上不产生锁对象，不占用内存空间。

例如update test set code=100 where id=10;执行的时候code=10的索引(code是二级索引，见文中给出的建表语句)会被加隐式锁，只有隐式锁产生冲突时才会变成显式锁(如S锁、X锁)。即此时另一个事务也去更新id=10这条记录，隐式锁就会升级为显示锁。
这样做的好处是降低了锁的开销。

UPDATE可能会导致新的普通索引的插入。当新的索引插入之前，会首先执行一次重复索引检查。在重复检查和插入时，更新操作会对受影响的二级索引记录采用共享锁定(S锁)。

2.2 DELETE语句

DELETE FROM ... WHERE ...在搜索遇到的每条记录上设置一个独占的next-key锁,如果是唯一索引只锁定记录。

3 INSERT

INSERT区别于UPDATE系列单独列出，是因为它的处理方式较为特别。

插入行之前，会设置一种插入意向锁，插入意向锁表示插入的意图。如果其它事务在要插入的位置上设置了X锁，则无法获取插入意向锁，插入操作也因此阻塞。

INSERT在插入的行上设置X锁。该锁是一个Record锁，并不是next-key锁，即只锁定记录本身，不锁定间隙，因此不会阻止其他会话在这行记录前的间隙中插入新的记录。
具体的加锁过程，见下一篇文章的第二章节(InnoDB的锁机制浅析(五)—InnoDB死锁场景)[https://www.cnblogs.com/AaronCui/p/10508831.html]。