14.7.2.1 事务隔离级别
事务隔离是数据库处理的基础之一。隔离是缩写ACID中的 I；隔离级别是一种设置，用于在多个事务同时进行更改和执行查询时微调性能与结果的可靠性，一致性和可重复性之间的平衡。
InnoDB提供了 SQL：1992 标准描述的所有四个事务隔离级别：READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ和SERIALIZABLE。 InnoDB的默认隔离级别是REPEATABLE READ。
用户可以使用SET TRANSACTION语句更改单个会话或所有后续连接的隔离级别。要为所有连接设置服务器的默认隔离级别，请在命令行或选项文件中使用--transaction-isolation选项。有关隔离级别和级别设置语法的详细信息，请参见第 13.3.6 节“ SET TRANSACTION 语句”。
InnoDB使用不同的locking策略支持此处描述的每个事务隔离级别。您可以对ACID合规性很重要的关键数据进行操作，与默认REPEATABLE READ级别保持高度一致性。或者，您可以使用READ COMMITTED甚至是READ UNCOMMITTED放宽一致性规则，例如在批量报告中，精确的一致性和可重复的结果不如最小化锁定开销重要。 SERIALIZABLE强制执行比REPEATABLE READ更为严格的规则，并且主要用于特殊情况下，例如XA事务以及对并发和deadlocks进行故障排除。
下 table 描述了 MySQL 如何支持不同的事务级别。列 table 从最常用的级别到最不常用的级别。
这是InnoDB的默认隔离级别。同一事务中的Consistent reads读取了由第一次读取构建的snapshot。这意味着，如果您在同一事务中发出几个简单的(非锁定)SELECT语句，则这些SELECT语句彼此之间也是一致的。参见第 14.7.2.3 节“一致的非锁定读取”。
对于locking reads(带有FOR UPDATE或LOCK IN SHARE MODE的SELECT)，UPDATE和DELETE语句，锁定取决于该语句是使用具有唯一搜索条件的唯一索引还是范围类型搜索条件。
-
对于具有唯一搜索条件的唯一索引，
InnoDB仅锁定找到的索引记录，而不锁定之前的gap。- 对于其他搜索条件，
InnoDB锁定扫描的索引范围，使用gap locks或next-key locks阻止其他会话插入该范围所覆盖的间隙。有关间隙锁和下一键锁的信息，请参见第 14.7.1 节“ InnoDB 锁定”。
- 对于其他搜索条件，
即使在同一事务中，每个一致的读取都将设置并读取其自己的新快照。有关一致读取的信息，请参见第 14.7.2.3 节“一致的非锁定读取”。
对于锁定读取(带有FOR UPDATE或LOCK IN SHARE MODE的SELECT)，UPDATE语句和DELETE语句，InnoDB仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定记录旁边自由插入新记录。间隙锁定仅用于外键约束检查和重复键检查。
由于禁用了间隙锁定，因此可能会产生幻影问题，因为其他会话可以在间隙中插入新行。有关幻像的信息，请参见第 14.7.4 节“幻像行”。
READ COMMITTED隔离级别仅支持基于行的二进制日志记录。如果将READ COMMITTED与binlog_format=MIXED一起使用，则服务器将自动使用基于行的日志记录。
使用READ COMMITTED具有其他效果：
请考虑从该 table 开始的以下示例：
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;
在这种情况下，table 没有索引，因此搜索和索引扫描将隐藏的聚集索引用于记录锁定(请参见第 14.6.2.1 节“群集索引和二级索引”)，而不是使用索引列。
假设一个会话使用以下语句执行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
第二个UPDATE会在尝试获取任何锁时立即阻止(因为第一次更新已在所有行上保留了锁)，并且直到第一个UPDATE提交或回滚后才 continue 进行：
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)
对于第二个UPDATE，InnoDB进行“半一致”读取，将它读取的每一行的最新提交版本返回给 MySQL，以便 MySQL 可以确定该行是否与UPDATE的WHERE条件匹配：
x-lock(1,2); update(1,2) to (1,4); retain x-lock
x-lock(2,3); unlock(2,3)
x-lock(3,2); update(3,2) to (3,4); retain x-lock
x-lock(4,3); unlock(4,3)
x-lock(5,2); update(5,2) to (5,4); retain x-lock
但是，如果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;
使用READ COMMITTED隔离级别的效果与启用已弃用的innodb_locks_unsafe_for_binlog配置选项相同，但以下情况除外：
-
启用innodb_locks_unsafe_for_binlog是全局设置，会影响所有会话，而隔离级别可以针对所有会话全局设置，也可以针对每个会话单独设置。
- innodb_locks_unsafe_for_binlog只能在服务器启动时设置，而隔离级别可以在启动时设置或在运行时更改。
因此READ COMMITTED比innodb_locks_unsafe_for_binlog提供了更好，更灵活的控制。
SELECT语句以非锁定方式执行，但是可能会使用行的早期版本。因此，使用此隔离级别，此类读取不一致。这也称为dirty read。否则，此隔离级别的作用类似于READ COMMITTED。
此级别类似于REPEATABLE READ，但是InnoDB如果禁用了autocommit，则将所有普通SELECT语句隐式转换为选择...锁定共享模式。如果启用了autocommit，则SELECT是其自身的事务。因此，它被认为是只读的，并且如果以一致的(非锁定)读取方式执行并且不需要阻塞其他事务就可以序列化。 (如果其他事务已修改所选行，则要强制普通SELECT阻止，请禁用autocommit。)
