MySQL事务隔离级别深入理解-工具盒子

1.事务 {#1.%E4%BA%8B%E5%8A%A1}

MySQL事务是指一组数据库操作，这些操作要么全部执行成功，要么全部不执行。
如果其中任何一个操作失败，整个事务都会被回滚，即所有操作都会被撤销，数据库回到事务开始之前的状态。这样可以保证数据的一致性和完整性，避免了数据丢失或者不一致的情况。

2.事务特性 {#2.%E4%BA%8B%E5%8A%A1%E7%89%B9%E6%80%A7}

事务是由 MySQL 的引擎来实现的，我们常见的 InnoDB 引擎它是支持事务的。

不过并不是所有的引擎都能支持事务，比如 MySQL 原生的 MyISAM 引擎就不支持事务，也正是这样，所以大多数 MySQL 的引擎都是用 InnoDB。

事务4大特性(ACID)：原子性、一致性、隔离性、持久性

原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，而且事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样，就好比买一件商品，购买成功时，则给商家付了钱，商品到手；购买失败时，则商品在商家手中，消费者的钱也没花出去。
一致性（Consistency）：是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。比如，用户 A 和用户 B 在银行分别有 800 元和 600 元，总共 1400 元，用户 A 给用户 B 转账 200 元，分为两个步骤，从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后，最后的结果是用户 A 还有 600 元，用户 B 有 800 元，总共 1400 元，而不会出现用户 A 扣除了 200 元，但用户 B 未增加的情况（该情况，用户 A 和 B 均为 600 元，总共 1200 元）。
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，因为多个事务同时使用相同的数据时，不会相互干扰，每个事务都有一个完整的数据空间，对其他并发事务是隔离的。也就是说，消费者购买商品这个事务，是不影响其他消费者购买的。
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

InnoDB 引擎通过什么技术来保证事务的这四个特性的呢？

持久性是通过 redo log （重做日志）来保证的；
原子性是通过 undo log（回滚日志）来保证的；
隔离性是通过 MVCC（多版本并发控制）或锁机制来保证的；
一致性则是通过持久性+原子性+隔离性来保证；

3.事务隔离级别 {#3.%E4%BA%8B%E5%8A%A1%E9%9A%94%E7%A6%BB%E7%BA%A7%E5%88%AB}

MySQL事务隔离级别是指在多个事务同时访问数据库时，数据库如何保证数据的一致性和隔离性。常见的隔离级别如下：

读未提交 ：最低的隔离级别。事务可以读取到其他事务尚未提交的数据，可能会出现脏读、不可重复读和幻读问题。
读已提交 ：事务只能读取到已经提交的数据。但在同一事务中，多次读取同一行的数据结果可能会不一致，可能会出现不可重复读和幻读问题。
可重复读 ：在同一个事务内，多次读取同一行的数据结果始终保持一致。MySQL的默认隔离级别就是可重复读 。通过使用MVCC机制来实现，在读操作期间不会看到其他事务的修改，有效地解决了不可重复读问题。
串行化 ：最高的隔离级别。事务串行执行，避免了脏读、不可重复读和幻读等问题。但是并发性能较差，可能导致大量的锁竞争和资源争用。

| 隔离级别 | 并发问题 | 适用场景 | |------------------------|------------------|------------| | 可串行化（serializable） | 不会产生干扰 | 数据一致性要求非常高 | | 可重复读（repeatable-read） | 可能会导致幻读 | 数据一致性要求较高 | | 读已提交（read-committed） | 可能会导致幻读或不可重复读 | 并发性要求较高 | | 读未提交（read-uncommitted） | 可能会导致脏读、幻读或不可重复读 | 并发性要求不高 |

隔离级别从上往下，由高到低。隔离级别越高，事务的并发性能就越低。

在实际应用中，需要根据具体情况选择合适的隔离级别，平衡数据的一致性和并发性能。例如，在高并发的Web应用程序中，可以选择可重复读隔离级别，以保证数据的一致性和并发性能。

脏读（Dirty Reads）：事务A读取到了事务B已经修改但尚未提交的数据

不可重读（Non-Repeatable Reads）：事务A内部的相同查询语句在不同时刻读出的结果不一致

幻读（Phantom Reads）：事务A读取到了事务B提交的新增数据

这三个现象的严重性排序如下：

3.1.数据准备 {#3.1.%E6%95%B0%E6%8D%AE%E5%87%86%E5%A4%87}


DROP TABLE test;
CREATE TABLE test (id INT PRIMARY KEY, name VARCHAR(20), balance INT);
INSERT INTO test VALUES (1, 'Alice', 1000);

3.2.读未提交（read-uncommitted） {#3.2.%E8%AF%BB%E6%9C%AA%E6%8F%90%E4%BA%A4%EF%BC%88read-uncommitted%EF%BC%89}

事务A修改balance并且不提交事务，事务B读取balance值为900；

如果此时事务A回滚数据，事务B读取balance值为1000（脏读）；

# 事务A
set tx_isolation = 'read-uncommitted';
BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM test WHERE id = 1;

@1
===



rollback
COMMIT;


事务B
===



set tx_isolation = 'read-uncommitted';
BEGIN;
SELECT balance FROM test WHERE id = 1;


@1:rollback后
============


`SELECT balance FROM test WHERE id = 1;
commit;`

3.3.读已提交（read-committed） {#3.3.%E8%AF%BB%E5%B7%B2%E6%8F%90%E4%BA%A4%EF%BC%88read-committed%EF%BC%89}

事务A修改balance并且不提交事务，事务B读取balance为1000；当事务A提交后，事务B读取balance值为900；

再重新开启事务A修改balance并提交事务，事务B中在读取balance值为800(整个过程事务B都不提交)（不可重复读）；

update test set balance = 1000 where id = 1;
# 事务A
set tx_isolation = 'read-committed';
BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM test WHERE id = 1;
COMMIT;

@2：再次修改balance并提交事务
===================



BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM test WHERE id = 1;
COMMIT;


事务B
===



set tx_isolation = 'read-committed';
BEGIN;


事务A提交前
======



SELECT balance FROM test WHERE id = 1;


事务A提交后
======



SELECT balance FROM test WHERE id = 1;


@2：再次查询balance
==============


`SELECT balance FROM test WHERE id = 1;
commit;`

3.4.可重复读（repeatable-read） {#3.4.%E5%8F%AF%E9%87%8D%E5%A4%8D%E8%AF%BB%EF%BC%88repeatable-read%EF%BC%89}

事务A修改balance并且不提交事务，事务B读取balance为1000；当事务A提交后，事务B读取balance值为1000；

开启事务A修改balance并提交事务，事务B中在读取balance值为1000（可重复读）(整个过程事务B都不提交)；

开启事务A插入为2的记录，事务B无法读取到2的记录，此时修改id为2balance+1000，可以修改成功，重新读取为2的记录balance为3000（幻读）(整个过程事务B都不提交)

update test set balance = 1000 where id = 1;
# 事务A
set tx_isolation = 'repeatable-read';
BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM test WHERE id = 1;
COMMIT;

@1:再次修改balance
==============



BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM test WHERE id = 1;
COMMIT;


@2:插入id:2记录
===========



BEGIN;
INSERT INTO test VALUES (2, 'Alice2', 2000);
COMMIT;


事务B
===



set tx_isolation = 'repeatable-read';
BEGIN;


事务A提交前
======



SELECT balance FROM test WHERE id = 1;


事务A提交后
======



SELECT balance FROM test WHERE id = 1;


@1:再次查询balance
==============



SELECT balance FROM test WHERE id = 1;


@2:查询id:2的记录
============



SELECT balance FROM test WHERE id = 2;


修改id:2的balance，修改成功
===================



update test set balance = balance + 1000 where id = 2;


查询id:2的记录
=========


`SELECT balance FROM test WHERE id = 2;
commit;`

3.5.可串行化（serializable） {#3.5.%E5%8F%AF%E4%B8%B2%E8%A1%8C%E5%8C%96%EF%BC%88serializable%EF%BC%89}

事务A修改balance并且不提交事务，事务B无法读取balance值（阻塞中），当事务A提交后，事务B才能读取balance值为1000（修改与读取串行化，不能同时执行）

update test set balance = 1000 where id = 1;
# 事务A
set tx_isolation = 'serializable';
BEGIN;
UPDATE test SET balance = balance - 100 WHERE id = 1;
COMMIT;

事务B
===


`set tx_isolation = 'serializable';
BEGIN;
SELECT balance FROM test WHERE id = 1;
commit;`