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死锁场景)[http://www.javashuo.com/article/p-vxeyibie-gh.html]。