InnoDB：Lock & Transaction

InnoDB 是一个支持事务的Engine，要保证事务ACID，必然会用到Lock。就像在Java编程一下，要保证数据的线程安全性，必然会用到Lock。了解Lock，Transaction可以帮助sql优化、deadlock分析等。

1、Lock
2、Transaction
3、DeadLock

1、Lock

InnoDB中，有多种类别的锁，下面将一一说明。

1.1 Shared Lock & Exclusive Lock

共享锁（S）与排他锁（X），这两个锁是row-level的锁，也就是说，可以理解为，每一行记录都有一把S，一把X锁。共享锁是读锁（Read Lock），事务执行时，如果要读取一行数据，就要先持有该行数据的读锁（S）。排他锁是写锁（Write Lock），事务执行时，如果要写数据（即更新数据，例如update, delete），则要先持有相应的行的写锁（X）。

此外，Read Lock可以同时被多个事务（实际上是执行这多个事务的线程）持有，Write Lock则不能。这一点，从设计上来讲，和java中的ReadLock WriteLock是类似的。

也就是说ReadLock可以同时被多个线程持有，WriteLock只能被一个线程持有。

当一个线程A持有着ReadLock（S）时，线程B也可以持有ReadLock（S），但线程B不能去持有WriteLock（X）。同时线程A如果持有着ReadLock时，如果还想再去持有WriteLock，那么必须等待其他的线程释放ReadLock，并且没有持有WriteLock。

当一个线程A持有着WriteLock时，其他的线程不能去持有WriteLock或者ReadLock，但他自己（线程A）还是可以去读取的，而不需要去持有ReadLock。

1.2 Intention Lock

意向锁，想要做某事时的锁，这是个表锁。分为两种：意向读锁（IS）、意向写锁（IX）。

如果你想要读取某些行的记录，必须得先持有表的IS锁。想要修改、删除某些行时，必须得先持有表的IX锁。

	X	IX	S	IS
X	Conflict	Conflict	Conflict	Conflict
IX	Conflict	Compatible	Conflict	Compatible
S	Conflict	Conflict	Compatible	Compatible
IS	Conflict	Compatible	Compatible	Compatible

使用意向锁，有两个好处：1、能够很快的进行上锁、或者不上锁操作，因为开启意向锁之后，有一个线程持有一把读锁或者意向读锁后，另外一个线程想要持有写锁，就要先去持有意向写锁，而意向写锁很容易就知道了暂时拿不到。如果不使用意向锁，那么就得先找到这条记录，找到记录后，发现该行记录的读锁因为已经被其他线程持有，而不能完成写锁的持有。这样白白的浪费了查找的时间。

2、能够有效的避免死锁的发生。

但是也因为是表锁，粒度太大，导致并发很低差。在多个事务同时操作一张表时，就变成了串行操作的了。

1.3 Records Lock (Index Record Lock)

记录锁，其实是index record Lock，也就是index row lock，不是数据row lock。Index Record Lock分为两种：S\X锁，也就是对index row加上S、X锁。

SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 如果c1是索引，将通过对c1=10的index 加上X Lock，这样就可以阻止任何其他的事务去持有t.c1=10 的索引锁。也就是说其他的事务中， inserting、 update、 delete操作是拿不到t.c1=10的索引锁的。

1.4 Gap Lock

缝隙锁，所谓gap是指两个索引之间的gap。每一个gap也有一把锁，称为gap lock。在第一条数据之前，最后一条数据之后，也各有一个gap，所以也有gap lock。

Gap Lock可以有效的避免幻读发生。例如一个事务A在执行SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 同时另一个事务B要insert 一个 c1=15的行。此时事务B是拿不到gap lock的，因为10到20直接的gaps locks都被事务A持有。此时并不会管有没有一条c1=15的记录存在，事务B都拿不到Gap。

Gap Lock可以显式的禁用，具体方式是设置隔离级别为READ_COMMMITED或者设置系统变量：Innodb_locks_unsafe_for_binlog。这种情况下，在scan index时是无效的，只会在foreign-key检查时才会有效。也可以理解成：一个事务如果是REPEATABE_READ隔离级别，则（可能）会Gap Lock 。这是说的可能，是因为有一个特殊情况：如果一个select语句只是从一个唯一索引的表，查询一条记录时，是不会使用gap lock的，因为没有必要的。

SELECT * FROM child WHERE id = 100;

Id是索引，并且唯一的。此时执行上述SQL时，最多只会找到一行记录，就不需要持有gap lock，而是直接持有index record lock。

1.5 Next-Key Lock

一个next-key lock是结合了一个index lock和它之前的gap lock。

InnoDB的默认隔离级别是：REPEATABLE_READ，这种隔离级别下，InnoDB使用在index scan 时，采用的是next-key。Next-key 本身不存在，只代表了index lock和它之前的gap lock。

2、Transaction

2.1事务数据库可能发生的问题有哪些？

Dirty reads: （脏读）一个事务A读到了另一个事务B还没有提交的数据（未提交的增删改的数据）。此时事务A就发生了脏读。因为有可能事务B不再提交这个数据，那么A就是读到的垃圾数据。

Fuzzy or non-repeatable reads: 当一个事务内，重新读取之前已经读过的数据时，发现读取到了其他的事务修改了某些数据或者删除了某些数据。

Phantom reads: （幻读）在一个事务内，重新执行一个查询时，发现有其他的已提交的事务插入了新的数据符合查询条件的数据。

2.2 ACID

Atomicity：事务是一个原子操作，对其数据的修改，要么全部执行，要么都不执行。

Consistent：连续性，一致性。必须保证一个事务内，连续两次执行同样的查询，执行结果是一样的。

Isolation：隔离性。事务提供了几种不同的隔离级别。隔离是值事务与事务之间的隔离，隔离强度越大，出现的问题就越少。

Durable：持久性。事务完成后，数据的变更是持久化的。MySQL InnoDB通过undo来保证持久性。

2.3 MVCC

在说隔离级别前，先了解一下MVCC（Multi-Version-Concurrency-Control）。

https://en.wikipedia.org/wiki/Multiversion_concurrency_control

大致意思就是：当数据库采用MVCC方案来设计事务时，通常是这样的：

当修改一行时，在提交之前，在内存中，不会使用新数据直接覆盖老数据，而是对老版本数据做一个标记，并创建一个新版本的数据。并且老版本的数据与新版本的数据是一个链式结构。如此一来，每一个修改的数据都有一个history chain。

当删除一行数据时，在提交之前，不会真的将数据从内存中删除，只是做一个删除标记罢了。

这里可以了解到变更的数据都有一个history chain。也就是说在内存中保留了相关Row的多个版本。保留多个版本，那么在进行并发读取时，就会大大提供并发量。

这也是MVCC最大的好处：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不重读非常重要。会极大的增加系统的并发性能。这也是为什么现阶段所有的RDBMS，都支持MVCC。

在运行时，不同的SQL语句采用不同的数据读取方式。根据读取方式的不同，分为snapshot读和current 读。上面说的读不加锁，读写不冲突是针对snapshot读而言的。而对于当前读（读取最新数据），还是要加锁的。

快照读：通常情况下，像这样简单的Select，是从snapshot读取的：

select * from table where ?;

当然也有例外，如果一个事务是READ_UNCOMMITED，即便是简单的Select，也会采用current读。

对于从临时表（包括嵌套查询生成的表）读取时，会采用current读。

Snapshot如何建立？

对于不同的隔离级别，Snapshot建立方式也是不同的，这里不做详细说明，在隔离级别小节中说明。

下面例子采用current读：

select * from table where ? lock in share mode; // S Lock

select * from table where ? for update; // X Lock and Index Lock

insert into table values (…); // X Lock

update table set ? where ?; // X Lock

delete from table where ?; // X Lock

2.4 两阶段锁（2PL）管理

在MySQL中，锁采用两阶段处理方式，即分为加锁阶段、释放锁阶段。

在2.3中，将Insert、update、delete都划归到 current读方式中。为什么呢？

下面看看Update执行过程：

Update分为多轮进行，每一轮都有信号交流过程：current read、lock & return、 update row、success。Delete也是如此的。

对于Insert则略有不同，因为他要先查找是否存在同样的Key。

从这个过程中，可以看出每一轮进行一个current read，并加锁，直到读完为止。Update完毕，并不会立即释放锁，而是接着执行，直到事务提交时才释放锁，insert, delete也同样如此：

2.5 隔离级别

READ UNCOMMITED：顾名思义，未提交的数据也可以读。其实，这种隔离级别下，Select语句在执行时，能够读取到相关行的当前版本（也就是最新版本），所以一些没有提交的事务对数据的变更，也能读取到。故而可能发生脏读了。

在此种隔离级别下，采用的是current读，所以也不会创建Snapshot了。

READ COMMITED：读取已提交的数据行。每一次都会读取已提交的数据行，所以每一次Select都要刷新到最新的Snapshot。所以他会发生不可重复读的问题，必然的，幻读也会发生。

REPEATABLE READ:可重复读。为了保证能够在同一个事务内可重复读，在一个事务开启后，由第一条要采用Snapshot方式的SQL（该select SQL未必是当前事务中的）来触发Snapshot的建立。这个也是InnoDB默认的隔离级别。

Session A Session B

SET autocommit=0; SET autocommit=0;

time

| SELECT * FROM t;

| empty set

| INSERT INTO t VALUES (1, 2);

v SELECT * FROM t;

empty set

COMMIT;

SELECT * FROM t;

empty set

COMMIT;

SELECT * FROM t;

---------------------

| 1 | 2 |

---------------------

SERIALIZABLE：序列化。对于该级别的事务，如果客户端采用了autocommit的事务，则直接提交，那么连接下的每一个SQL都是一个单独的事务。如果没有采用autocommit方式，则采用REPEATABLE READ隔离级别，但是会将所有的简单的Select转换为Select ... LOCK IN SHARE MODE，即转为current 读。

读数据一致性及允许的并发副作用隔离级别	读数据一致性	脏读	不重复读	幻读
未提交读（Read uncommitted）	最低级别，只能保证不读取物理上损坏的数据	可能	可能	可能
已提交度（Read committed）	语句级	否	可能	可能
可重复读（Repeatable read）	事务级	否	否	可能
可序列化（Serializable）	最高级别，事务级	否	否	否

2.6 SQL 加锁分析

·select ... from ... Lock IN SHARE MODE （也称为加锁read）

默认情况下（REPEATABLE_READ），这个select SQL中如果使用了index，会在所有匹配行的index record上，加上shared next-key lock。如果select中使用的index是一个唯一索引的话，则只是在匹配行的index record上，加上shared index record Lock。

如果是更低的隔离级别READ_COMMITED、READ_COMMITED，则直接加shared index record。

·Select ... from (不加锁读)

如果执行该SQL的事务采用的是SERIALIZABLE级别，则会转为select ... from ... Lock IN SHARE MODE，也就是会变成加锁读。

在其它的隔离级别下，则不会加锁，是从snapshot中读取数据。

·select ... from ... FOR UPDATE

在REPEATABLE_READ、SERIALIZABLE隔离级别下，这个select SQL中如果使用了index，会在匹配的行上加上exclusive next-key lock。如果select中使用的index是一个唯一索引的话，则只是在匹配行的index record上，加上exclusive index record Lock。

如果是更低的隔离级别READ_COMMITED、READ_COMMITED，则直接加exclusive index record。

·UPDATE ... WHERE ...

如果是更低的隔离级别READ_COMMITED、READ_COMMITED，则直接加exclusive index record。

当执行update操作时，如果是在clustered index record（聚簇index）上，会隐式对所有的受影响的二级索引都加上锁。例如 table test 有聚簇index （a,b,c），那么index record 就是由a,b,c组成的。如果更新时使用：update test set d=’1’ where a=’1’ and b=’2’；这个 SQL在执行时，会对与a, b匹配的所有的index record 都加上锁exclusive。

·DELETE... WHERE ...

·INSERT

Insert 时会先查找有没有匹配的index，如果有：会在匹配的index上加上shared index Lock。

如果没有，会在某个要插入的row上加上exclusive index lock （没有对gap 加锁，防止对并发插入产生影响）。

如果在执行上述几种SQL时，没有使用到index，会引发全表扫描。在全表扫描时，并不会锁住整个表的。

有人可能会问？为什么不是只在满足条件的记录上加锁呢？这是由于MySQL的实现决定的。如果一个条件无法通过索引快速过滤，那么存储引擎层面就会将所有记录加锁后返回，然后由MySQL Server层进行过滤。因此也就把所有的记录，都锁上了。

注：在实际的实现中，MySQL有一些改进，在MySQL Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录放锁 (违背了2PL的约束)。这样做，保证了最后只会持有满足条件记录上的锁，但是每条记录的加锁操作还是不能省略的。

结论：若id列上没有索引，SQL会走聚簇索引的全扫描进行过滤，由于过滤是由MySQL Server层面进行的。因此每条记录，无论是否满足条件，都会被加上X锁。但是，为了效率考量，MySQL做了优化，对于不满足条件的记录，会在判断后放锁，最终持有的，是满足条件的记录上的锁，但是不满足条件的记录上的加锁/放锁动作不会省略。同时，优化也违背了2PL的约束。

3、DeadLock

事务A 持有row1的lock的同时，事务B持有row2的lock。然后事务A也想要去持有row2的Lock，但同时事务B又不会立刻马上释放row2的lock。这种情况下，就会在事务A中抛出DeadLock的错误。