事务隔离是数据库处理的基础之一。隔离是首字母缩略词 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
使用不同的锁定策略支持此处描述的每个事务隔离级别
。对于ACID合规性很重要REPEATABLE READ
的关键数据操作,
您可以强制使用默认级别的高度一致性
。或者,您可以放宽一致性规则
甚至
,在批量报告等情况下,精确一致性和可重复结果不如最小化锁定开销重要。
执行比 更严格的规则,主要用于特殊情况,例如XAREAD COMMITTED
READ UNCOMMITTED
SERIALIZABLE
REPEATABLE
READ
事务以及解决并发和
死锁问题。
下面的列表描述了 MySQL 如何支持不同的事务级别。该列表从最常用的级别到最少使用的级别。
这是 . 的默认隔离级别
InnoDB
。 同一事务中的 一致读取读取由第一次读取建立的快照。这意味着如果您SELECT
在同一个事务中发出多个普通(非锁定)语句,这些SELECT
语句也彼此一致。请参阅 第 14.7.2.3 节,“一致的非锁定读取”。对于锁定读取 (
SELECT
withFOR UPDATE
orLOCK IN SHARE MODE
) ,,,UPDATE
和DELETE
语句,锁定取决于语句是使用具有唯一搜索条件的唯一索引还是范围类型搜索条件。对于具有唯一搜索条件的唯一索引,
InnoDB
只锁定找到的索引记录,而不锁定 它之前 的间隙。对于其他搜索条件,
InnoDB
锁定扫描的索引范围,使用 间隙锁或 下一个键锁 来阻止其他会话插入到范围所覆盖的间隙中。有关间隙锁和下一键锁的信息,请参阅 第 14.7.1 节,“InnoDB 锁定”。
每个一致的读取,即使在同一个事务中,也会设置和读取它自己的新快照。有关一致性读取的信息,请参阅 第 14.7.2.3 节,“一致的非锁定读取”。
对于锁定读取(
SELECT
withFOR UPDATE
或LOCK IN SHARE MODE
)、UPDATE
语句和DELETE
语句,InnoDB
仅锁定索引记录,而不锁定它们之前的间隙,因此允许在锁定记录旁边自由插入新记录。间隙锁定仅用于外键约束检查和重复键检查。由于禁用了间隙锁定,因此可能会出现幻像行问题,因为其他会话可以将新行插入间隙中。有关幻影行的信息,请参阅 第 14.7.4 节,“幻影行”。
READ COMMITTED
隔离级别 仅支持基于行的二进制日志记录 。如果使用READ COMMITTED
withbinlog_format=MIXED
,服务器会自动使用基于行的日志记录。使用
READ COMMITTED
还有额外的效果:考虑以下示例,从该表开始:
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;
在这种情况下,该表没有索引,因此搜索和索引扫描使用隐藏的聚集索引进行记录锁定(请参阅第 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
执行 eachUPDATE
时,它首先为它读取的每一行获取一个独占锁,然后再决定是否修改它。如果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
提交或回滚之前不会继续: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,以便 MySQL 可以确定该行是否符合以下WHERE
条件UPDATE
: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
语句以非锁定方式执行,但可能会使用行的可能早期版本。因此,使用这个隔离级别,这样的读取是不一致的。这也称为 脏读。否则,这个隔离级别就像READ COMMITTED
.此级别类似于
REPEATABLE READ
,但将所有普通 语句InnoDB
隐式转换为if 已禁用。如果 启用,则这 是它自己的事务。因此已知它是只读的,如果作为一致(非锁定)读取执行并且不需要为其他事务阻塞,则可以序列化。(如果其他事务修改了选定的行,要强制一个普通 的阻塞,请禁用 。)SELECT
SELECT ... LOCK IN SHARE MODE
autocommit
autocommit
SELECT
SELECT
autocommit