MySQL 锁与MVCC ：数据库的锁、MVCC、当前读、快照读、锁算法、死锁

---

lock与latch

在了解数据库锁之前，首先就要区分开lock和latch。在数据库中，lock和latch虽然都是锁，却有着截然不同的含义。

latch通常被我们称为闩锁(轻量级锁)，因为其要求锁定的时间必须非常短。在InnoDB中，latch可以分为mutex(互斥锁)和rwlock(读写锁)，它的作用是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测机制。

lock的操作对象则是事务，用来锁定数据库中的对象，如表、页、行等，并且一半lock的对象仅在事务提交或者回滚后释放，并且lock有死锁检测机制，本篇博客介绍的也主要是lock，下面是lock和latch的区别。

---

锁的类型

在InnoDB存储引擎中实现了下面两种标准的行级锁

• 共享锁（S Lock) ：允许事务读一行数据
• 排他锁（X Lock) ：允许事务删除或者更新一行数据。

由于共享锁并不涉及到数据的修改，所以即使一个事务已经获得了行1的共享锁，另外的事务也可以立即获得行1的共享锁，这种情况又被称为锁兼容。

对于排他锁又是另一种情况，由于排他锁涉及到了数据的修改，为了保证安全，其他的事务想要获得同一行的排他锁时，必须要等到前一个事务释放锁才行，这种情况又被称为锁不兼容

下面是排他锁和共享锁的兼容性。

由于InnoDB支持多粒度锁定，所以允许事务可以同时存在行锁和表锁，为了支持在不同粒度上进行加锁操作，InnoDB支持一种额外的锁方式，即意向锁（Intention Lock）。意向锁即将锁定的对象分为多个层次，意味着希望事务在更细粒度上进行加锁，如下图。

如果我们想对下层的对象如记录上一个X锁，就需要先对粒度更粗的上层对象上锁，需要分别先对数据库、表、页上IX锁，再对记录上X锁。（防止我们对一行上了读锁之后，某个事务申请了一个表级的写锁，此时这个事务就会对我们上锁的数据进行修改，导致出现问题

InnoDB支持意向锁设计比较简练，其意向锁即为表级别的锁，设计目录主要是为了在一个事务中揭示下一行将被请求的锁的类型，两种意向锁分别如下

• 意向共享锁（IS Lock），事务要想获得某一张表中某几行的共享锁
• 意向排他锁（IX Lock），事务要想获得某一张表中某几行的排他锁

由于InnoDB支持的是行级别的锁，因此意向锁不会阻塞除全表扫描外的任何请求，故兼容性如下。

---

MVCC

MVCC（Multi-Version Concurrency Control）即多版本并发控制，是数据库并发控制的一种方法

一致性非锁定读（快照读）

一致性非锁定读又叫做快照读，如果我们读取的行正在执行DELETE或者UPDATE操作，这时就不会去等待锁释放后再读取，而是直接去读取行的一个快照数据，如下图所示

快照数据指的是该行之前版本的数据，这些数据存储在undo段中，由于undo用来在事务中回滚数据，因此这些快照数据本身并没有额外的开销。并且我们只是读操作，并不涉及修改，而且也没有事务会去对历史数据进行修改，所以在读取快照数据的时候不需要进行加锁。

因为读取操作不再占用和等待表上的锁，所以快照读的机制极大的提高了数据库的性能。由于每个快照都相当于是一个历史版本，所以这种对于行的多版本技术带来的并发控制，就是MVCC名字的由来。

需要注意的是，MVCC只在READ COMMITTED（读已提交） 和 REPEATABLE READ（可重复读）两个隔离级别下工作。由于READ UNCOMMITTED（读未提交）总会读取在最新的数据，而SERIALIZABLE（可串行化）会对所有读取的行加锁，所以这两种都不兼容MVCC

一致性锁定读（当前读）

一致性锁定读又称为当前读，它与快照读刚好相反，它读取的是行的最新版本，并且读取的时候为了防止其他事务不会修改当前行，还会对当前行进行加锁。

在InnoDB中，对于SELECT语句支持以下两种一致性锁定读操作

• SELECT…FOR UPDATE(排他锁)
• SELECT…LOCK IN SHARE MODE(共享锁)

SELECT…FOR UPDATE会对读取的行加一个排他锁，此时其他事务不能对该行上任何锁。

SELECT…LOCK IN SHARE MODE会位读取的行加上一个共享锁，此时其余的事务可以对该行加上共享锁，但是如果相加排他锁，则会被阻塞。

---

锁算法

在InnoDB中由三种行锁的算法

• Record Lock（记录锁）：单个行记录上的锁
• Gap Lock（间隙锁） ： 锁定一个范围，但不包含记录本身
• Next-Key Lock（下一键锁） ：前两种锁的结合，既锁定一个范围，也锁定记录本身

为了更好的理解他们的区别，我拿一组数据来进行举例

有一组数据，其索引分别为10、30、60
此时使用SQL语句SELECT * FROM t WHERE id = 10 FOR UPDATE，三种锁的范围如下

• Record: 对10单行进行加锁
• Gap Lock : (-∞， 10)、(10, 30)、(30， 60)、(60， +∞)
• Next-Key Lock : (-∞，10]、(10，30]、(30，60]、(60，+∞)

对于Record Lockl来说，其总是会去锁住索引记录，即使没有设置任何一个索引，它也会使用隐式的索引进行锁定。

Next-Key Lock是结合了前面所说的两种锁算法，既锁住范围，也锁住记录本身，在InnoDB中对于行的查询都会采用这种算法，而设计它的目的正是为了解决幻读问题。

在上一篇博客中也说了，幻读指在同一事务中，用同样的操作读取两次，得到的记录数却不一样。（针对同一个范围的数据）。 主要原因就是当第一个事务对表中的数据进行修改，并且这个涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，向其中插入了一行。这样也就导致了操作第一个事务的用户发现表中还有没修改的数据行，像发生了幻觉一样。

明明在会话A的第一次查询中，大于2的数只有行只有一列，而由于会话B插入了新列后，对于会话A而言就凭空多出来了一列，像出现了幻觉一样。

对于以上数据，Next-Key Locking算法在SELECT * FROM t WHERE a > 2 FOR UPDATE这条语句中，锁住的不仅仅是5这个数值，而是对直接对（2，+∞）这个范围加了排他锁，所以任何对于这个范围的插入都不能进行，也就避免了幻读现象的发生。

同理，间隙锁Gap Lock也是锁定某个范围，所以它也能防止幻读的出现。

InnoDB正是借助锁(Gap Lock、Next-Key Lock)以及MVCC(快照读)这两个机制实现了事务的隔离性

---

死锁

死锁指的是两个或者两个以上的事务在执行过程中，因为争抢所资源而导致的一种互相等待的现象。在死锁的情况下，如果没有外力作用，事务将永远无法推进下去。

在数据库中通常都会使用超时机制来解决死锁。即为事务设置超时时间，即使两个事务互相等待，当其中一方超时后立刻进行回滚，另一个事务就能够继续进行了。

虽然超时机制可以解决这个问题，但是我们并不能掌握回滚的事务的量级，倘若事务更新庞大，则回滚就会带来大量的性能损耗，所以我们通常会采用更加主动的策略，即使用等待图来进行死锁检测，如下图。

• 图中每个节点即为一个事务
• 每条指向其他节点的线则代表着正在等待该节点的资源
• 当存在回路时，则代表着事务互相等待，此时就意味着存在死锁

每当事务请求锁并发生等待时，都会主动判断等待图中是否存在回路，如果存在则代表着有死锁产生，此时就会主动选择undo量最小的事务来打破死锁。在现版本的InnoDB中，通常采用深度优先搜索(老版本使用递归)来检测死锁的存在。

---

锁升级

在数据库为了保证安全，大量的并发下必定存在着大量的锁，由于锁是一种稀有资源，为了避免大量锁的开销，数据库中存在着锁升级的机制。

锁升级指的是将当前的锁升级为更粗粒度的锁，例如我们可以将多个行锁升级为一个页锁，又或者将多个页锁升级为一个表锁。这种升级保护了系统资源，防止系统使用太多内存来维护大量的锁，在一定程度上提高了效率。

在SQL Server中，锁升级是很常见的现象，当满足以下条件中其中一个时则会进行锁升级

• 锁资源占用的内存超过了激活内存的40%
• 由一条单独的SQL语句在一个对象上持有的锁数量超过了阈值，阈值默认为5000

而在MySQL的InnoDB中，则不存在锁升级的问题。其根据每个事务访问的每个页对锁进行管理，并且使用位图来标记，所以一个事务无论锁住页中多少条记录，开销都相同