锁相关

1.1 lock 与 latch

latch 一般称为闩锁（轻量级的锁），因为其要求锁定时间必须非常短。在 InnoDB 存储引擎中，latch 又分为 mutex 和 rwlock 。其目的是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测机制。

lock 的对象是事务，用来锁定的是数据库中的对象，如表、行、页。并且一般 lock 的对象仅在事务 commit 或 rollback 后释放，并且是有死锁机制的。

	lock	latch
对象	事务	线程
保护	数据库内容	内存数据结构
持续时间	整个事务过程	临界资源
模式	行锁、表锁、意向锁	读写锁、互斥量
死锁	通过 waits-for graph、time out 等机制进行检测与处理	无死锁检测与处理机制
存在于	Lock Manager 的哈希表中	每个数据结构的对象中

1.2 InnoDB 存储引擎中的锁

1.2.1 锁的类型

• 共享锁（ S 锁），允许事务读一行数据（行级）
• 排他锁（ X 锁），允许事务删除或更新一行数据（行级）
• 意向共享锁（ IS 锁），事务想要获得一张表中某几行的共享锁（表级）
• 意向排他锁（ IX 锁），事务想要获得一张表中某几行的排他锁（表级）

这里说一下意向锁。意向锁是为了保证行锁和表锁可以共存。

考虑以下两种情况：

1. 想要对表加 S 锁，那么就要先确定表中的行是否有 X 锁，没有的话才可以加表锁
2. 想要对表加 X 锁，类似地，需要确定表里是否有 S 锁或 X 锁，没有的话才可以加表锁

而为了确定表中是否有锁，很自然的就应该去遍历表的每一行，确定每一行的锁的情况。但是，这样的效率太低了。因此，InnoDB 提出了意向锁。在对每一行记录加行锁前，先对表加意向锁，这样当以后要需要对表加锁时，就可以直接根据表的意向锁来确定表里的加锁情况。回到之前说的情况，现在想要对表加 S 锁时，只需要看表上是否有 IX 锁，没有的话可以直接加表锁。

	IS	IX	S	X
IS	兼容	兼容	兼容	不兼容
IX	兼容	兼容	不兼容	不兼容
S	兼容	不兼容	兼容	不兼容
X	不兼容	不兼容	不兼容	不兼容

需要注意的是表格上的 X 和 S 都是指的表锁。

1.2.2 一致性非锁定读

InnoDB 通过行多版本控制的方法来读取当前执行时间数据库中行的数据。如果读取的行上有 X 锁，不会等待，而是去读取行的上一个快照数据。这里也能理解为什么叫非锁定读了。

显然，非锁定读极大地提高了数据库的并发性，因此在默认情况下，这也是 InnoDB 的默认读取方式。但是，不同的隔离级别下，读取的方式不同！！！

1. READ COMMITTED ：读取最新的一份快照数据
2. REPEATABLE READ ：读取事务开始时的行数据版本

1.2.3 一致性锁定读

从上面可以知道，非锁定读虽然避免了加锁的操作，但是读到的数据不是最新的，而是历史的数据。而在某些情况下是需要读取实时的数据的，那么这时就不得不加锁了。

• SELECT … FOR UPDATE （ X 锁）

• SELECT … LOCK IN SHARE MODE （ S 锁）

1.2.4 外键和锁

在子表中对外键的值插入或更新，都需要先查询父表的记录，即 SELECT 父表。但是对于父表的 SELECT 操作并不是使用的一致性非锁定读的方式，而是对父表加 S 锁。这种情况下，如果父表上已经有了 X 锁，子表的操作只能被阻塞。

1.3 锁的算法

• Record Lock ：单个行记录上的锁
• Gap Lock ：间隙锁，锁定一个范围，但不包含记录本身
• Next-Key Lock ：锁定一个范围，并且锁定记录本身

需要明确的是，上面三种锁都是对某行记录加的。Record Lock 很好理解，就是对一行记录加锁。Gap Lock看起来有点奇怪，但是举个例子就很清楚了。比如说一个索引有1，6，8，10 四个值，Gap Lock 可以分为以下几个区间：(,1) , (1,6) , (6,8) , (8,10) , (10,) 。那么对索引值为 6 的记录加 Gap Lock 锁的就是 (1,6) 。而 Next-Key Lock 实际上就是 Gap Lock+Record Lock，因此其锁定的范围应该是 (1,6] 。但实际上还会对下一个索引值加上 Gap Lock，因此实际锁的范围应该是 (1,6] + (6,8) 。很自然的我们会想为什么要有 Gap Lock，其实这是用来避免幻读的，因此即使 InnoDB 默认的事务隔离级别是 REPEATABLE READ，幻读也是不会发生的。还有一点需要注意的是，当查询的索引含有唯一属性（可以理解为包含唯一索引）时，InnoDB 会将 Next-Key Lock 降为 Record Lock。

1.4 死锁

• 超时回滚
• wait-for graph，死锁检测

wait-for graph 要求数据库保存以下两种信息：

1. 锁的信息链表，确定图中结点间的指向
2. 事务等待链表，确定图中的结点有哪些

死锁.png

从图中可以看到 t1 和 t2 构成回路形成死锁。在每个事务请求锁并发生等待时，都会判断是否存在回路，若存在就说明有死锁，InnoDB 会回滚 undo 量最小的事务。