事务隔离级别

隔离级别是在多个事务同时进行更改和执行查询时，对性能与结果的可靠性、一致性和再现性之间的平衡进行微调的设置。

提供了SQL:1992标准中描述的四种事务隔离级别：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。InnoDB默认的隔离级别是REPEATABLE READ。

InnoDB使用不一样的锁定策略支持这里描述的每一个事务隔离级别。下面的列表描述了MySQL如何支持不一样的事务级别。

1.  REPEATABLE READ（可重复读）

这是InnoDB的默认隔离级别。同一个事务中的一致性读取读的是第一次读取时创建的快照。这意味着，若是在同一个事务中发出几个普通(非锁定)SELECT语句，这些SELECT语句彼此之间也是一致的。（PS：可重复读这个级别就是要保证同一个事务中，屡次读取相同的数据，返回的结果是同样的。）

对于锁定读（SELECT with FOR UPDATE or LOCK IN SHARE MODE）、UPDATE 和 DELETE 语句，锁定取决于语句是使用具备惟一搜索条件的惟一索引，仍是使用范围类型的搜索条件。

• 对于具备惟一搜索条件的惟一索引，InnoDB只锁定找到的索引记录，而不锁定之间的间隙。
• 对于其余搜索条件，InnoDB锁定扫描到的索引范围，使用间隙锁或next-key锁以阻止其余会话向该范围覆盖的间隙中插入。 

2.  READ COMMITTED（读已提交）

即便在同一事务中，每一个一致的读取都将设置并读取本身的新快照。（PS：对比一下，对于一致性读，可重复读是读取事务中第一次读取时候创建的快照；而读已提交，每次都是读最新的快照）

对于锁读（SELECT with For UPDATE or LOCK IN SHARE MODE）、UPDATE语句和DELETE语句，InnoDB只锁住索引记录，而不锁住它们之间的间隙，从而容许在锁住的记录旁边自由插入新记录。间隙锁定仅用于外键约束检查和重复键检查。 

因为禁用了间隙锁，可能会出现幻像问题，由于其余会话能够在间隙中插入新行。

使用READ COMMITTED具备额外的效果：

• 对于UPDATE或DELETE语句，InnoDB仅对其更新或删除的行持有锁。MySQL评估WHERE条件后，将释放不匹配行的记录锁。这大大下降了死锁的可能性，可是仍然可能发生。
• 对于UPDATE语句，若是某行已被锁定，则InnoDB执行“半一致”读取，将最新的提交版本返回给MySQL，以便MySQL能够肯定该行是否与UPDATE的WHERE条件匹配。若是该行匹配（必须更新），则MySQL会再次读取该行，这一次InnoDB将其锁定或等待对其进行锁定。 

举个例子，考虑下面的语句：

CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

在这种状况下，表没有索引，所以搜索和索引扫描使用隐藏的汇集索引锁定记录

假设，第一个会话要执行update语句：

# Session A
START TRANSACTION;
UPDATE t SET b = 5 WHERE b = 3;

假设，在第一个会话以后，第二个会话也要执行以下update语句：

# Session B
UPDATE t SET b = 4 WHERE b = 2;

当InnoDB执行每一个UPDATE时，它首先为读取的每一行获取一个排他锁，而后决定是否修改它。若是InnoDB没有修改该行，则释放锁。不然，InnoDB会保留锁直到事务结束。这对事务处理的影响以下。

若是用默认的REPEATABLE READ隔离级别，第一个UPDATE在其读取的每一行上获取一个X锁，而且不释放其中的任何一个：

x-lock(1,2); retain x-lock
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); retain x-lock
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); retain x-lock

（PS：之因此每一行都加排它锁，是由于b上没有惟一索引）

第二个UPDATE在尝试获取任何锁时当即阻塞（由于第一个UPDATE已在全部行上保留了锁），而且直到第一个UPDATE提交或回滚后才继续进行：

x-lock(1,2); block and wait for first UPDATE to commit or roll back

若是用READ COMMITTED隔离级别，第一个UPDATE在其读取的每一行上获取一个X锁，并为未修改的行释放X锁：

x-lock(1,2); unlock(1,2)
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); unlock(3,2)
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); unlock(5,2)

可是，若是WHERE条件包含一个索引列，而且InnoDB使用该索引，那么在获取和保留记录锁时，只考虑索引列。

再看下面一个例子，第一个UPDATE在b = 2的每一行上获取并保留一个X锁。第二个UPDATE在尝试获取同一记录上的X锁时会阻塞，由于它也使用在b列上定义的索引 。

CREATE TABLE t (a INT NOT NULL, b INT, c INT, INDEX (b)) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2,3),(2,2,4);
COMMIT;

# Session A
START TRANSACTION;
UPDATE t SET b = 3 WHERE b = 2 AND c = 3;

# Session B
UPDATE t SET b = 4 WHERE b = 2 AND c = 4;

（PS：b列上有索引，这两条语句在检索时使用了b列上的索引，所以第一会话在b=2的列上加了X锁，第一个会话更新b=2时会阻塞）

3.  READ UNCOMMITTED（读未提交）

会出现脏读，通常不使用

4.  SERIALIZABLE（串行化）

此级别相似于REPEATABLE READ，但若是禁用了自动提交，则InnoDB会将全部普通的SELECT语句隐式转换为SELECT ... LOCK IN SHARE MODE。