可重复读

这是InnoDB的默认隔离级别。一致读在同一事务中读取的快照由第一个读取建立。这意味着，如果您在同一事务中发出多个普通（非锁定）SELECT语句，这些SELECT语句也是一致的，相互之间也是一致的。请参阅第17.7.2.3节，“一致的非锁定读”。

对于锁定读（SELECT带FOR UPDATE或FOR SHARE）、UPDATE和DELETE语句，锁定取决于语句是否使用唯一索引具有唯一搜索条件，或者范围类型搜索条件。

已提交读取

每个一致读取，即使在同一事务中，也会设置并读取其自己的最新快照。有关一致读取的信息，请参见第 17.7.2.3 节，“一致非锁定读取”。

对于锁定读取 (SELECT 带 FOR UPDATE 或 FOR SHARE），UPDATE 语句和 DELETE 语句，InnoDB 只锁定索引记录，而不是它们之前的间隙，从而允许在锁定记录旁边自由插入新记录。间隙锁定仅用于外键约束检查和重复键检查。

因为间隙锁定被禁用，幽灵行问题可能会出现，因为其他会话可以在锁定记录旁边插入新行。有关幽灵行的信息，请参见第 17.7.4 节，“幽灵行”。

仅支持基于行的二进制日志记录与 已提交读取 隔离级别。如果您使用 已提交读取 与 binlog_format=MIXED，服务器将自动使用基于行的日志记录。

使用 已提交读取 还有其他效果：

考虑以下示例，始于以下表：

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;

在这种情况下，表没有索引，因此搜索和索引扫描使用隐藏的聚簇索引进行记录锁定（参见第 17.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 保持锁定直到事务结束。这影响事务处理如下。

使用默认的 可重复读取 隔离级别时，第一个 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 提交或回滚：

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

如果使用 READ COMMITTED，第一个 UPDATE 将在每个读取的行上获取 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 确定该行是否匹配 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 隔离级别。运行时，可以全局设置所有会话或单独设置每个会话。

READ UNCOMMITTED

SELECT 语句以非锁定方式执行，但可能使用早期版本的行。因此，使用这个隔离级别，读取不一致。这也称为 脏读。否则，这个隔离级别的工作方式与 READ COMMITTED 相同。

SERIALIZABLE

这个级别类似于 REPEATABLE READ，但 InnoDB隐式地将所有普通 SELECT 语句转换为 SELECT ... FOR SHARE，如果 autocommit 被禁用。如果 autocommit 被启用，则 SELECT 是其自己的事务。因此，它被认为是只读的，可以被序列化，如果执行为一致的（非锁定）读取，不需要阻塞其他事务。（要强制普通 SELECT 阻塞，如果其他事务修改了所选行，禁用 autocommit。）

DML 操作从 MySQL 授权表（通过连接列表或子查询）读取数据，但不修改它们，不会在 MySQL 授权表上获取读锁，不管隔离级别如何。有关更多信息，请参阅 Grant Table Concurrency。