事务

Weiser2025/6/21大约 8 分钟约 2485 字

事务

在维基百科中，对事务的定义是：事务是数据库管理系统(DBMS)执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。

事务的四大特性

事务包含四大特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）**和**持久性（Durability）(ACID)。

原子性（Atomicity） 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。以转账场景为例，一个账户的余额减少，另一个账户的余额增加，这两个操作一定是同时成功或者同时失败的。
一致性（Consistency） 一致性是指数据库的完整性约束没有被破坏，在事务执行前后都是合法的数据状态。这里的一致可以表示数据库自身的约束没有被破坏，比如某些字段的唯一性约束、字段长度约束等等；还可以表示各种实际场景下的业务约束，比如上面转账操作，一个账户减少的金额和另一个账户增加的金额一定是一样的。
隔离性（Isolation） 隔离性指的是多个事务彼此之间是完全隔离、互不干扰的。隔离性的最终目的也是为了保证一致性。
持久性（Durability） 持久性是指只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。

脏读、不可重复读、幻读

在事务并发执行时，如果不进行任何控制，可能会出现以下4类问题：

脏写（Dirty Write）

脏写是指一个事务修改了其它事务未提交的数据。

如上图，Session A和Session B各开启了一个事务，Session B中的事务先将number列为1的记录的name列更新为'关羽'，然后Session A中的事务接着又把这条number列为1的记录的name列更新为张飞。如果之后Session B中的事务进行了回滚，那么Session A中的更新也将不复存在，这种现象就称之为脏写。

如上图，Session A和Session B各开启了一个事务，Session B中的事务先将number列为1的记录的name列更新为'关羽'，然后Session A中的事务再去查询这条number为1的记录，如果读到列name的值为'关羽'，而Session B中的事务稍后进行了回滚，那么Session A中的事务相当于读到了一个不存在的数据，这种现象就称之为脏读。

不可重复读（Non-Repeatable Read）

不可重复读指的是在一个事务执行过程中，读取到其它事务已提交的数据，导致两次读取的结果不一致。如上图，我们在Session B中提交了几个隐式事务(mysql会自动为增删改语句加事务)，这些事务都修改了number列为1的记录的列name的值，每次事务提交之后，如果Session A中的事务都可以查看到最新的值，这种现象也被称之为不可重复读。

幻读（Phantom）

幻读是指的是在一个事务执行过程中，读取到了其他事务新插入数据，导致两次读取的结果不一致。如上图，Session A中的事务先根据条件number > 0这个条件查询表hero，得到了name列值为'刘备'的记录；之后Session B中提交了一个隐式事务，该事务向表hero中插入了一条新记录；之后Session A中的事务再根据相同的条件number > 0查询表hero，得到的结果集中包含Session B中的事务新插入的那条记录，这种现象也被称之为幻读。

不可重复读和幻读的区别在于不可重复读是读到的是其他事务修改或者删除的数据，而幻读读到的是其它事务新插入的数据。

脏写的问题太严重了，任何隔离级别都必须避免。其它无论是脏读，不可重复读，还是幻读，它们都属于数据库的读一致性的问题，都是在一个事务里面前后两次读取出现了不一致的情况。

隔离级别

在SQL标准中设立了4种隔离级别，用来解决上面的读一致性问题。不同的隔离级别可以解决不同的读一致性问题。

READ UNCOMMITTED：未提交读。
READ COMMITTED：已提交读。
REPEATABLE READ：可重复读。
SERIALIZABLE：串行化。

各个隔离级别下可能出现的读一致性问题如下：

隔离级别	脏读	不可重复读	幻读
未提交读（READ UNCOMMITTED）	可能	可能	可能
已提交读（READ COMMITTED）	不可能	可能	可能
可重复读（REPEATABLE READ）	不可能	不可能	可能（对InnoDB不可能）
串行化（SERIALIZABLE）	不可能	不可能	不可能

InnoDB支持四个隔离级别（和SQL标准定义的基本一致）。隔离级别越高，事务的并发度就越低。唯一的区别就在于，InnoDB 在可重复读（REPEATABLE READ）的级别就解决了幻读的问题。这也是InnoDB使用可重复读 作为事务默认隔离级别的原因。

MVCC

MVCC(Multi Version Concurrency Control)，中文名是多版本并发控制，简单来说就是通过维护数据历史版本，从而解决并发访问情况下的读一致性问题。

版本链

在InnoDB中，每行记录实际上都包含了两个隐藏字段：事务id(trx_id)和回滚指针(roll_pointer)。

trx_id：事务id。每次修改某行记录时，都会把该事务的事务id赋值给trx_id隐藏列。
roll_pointer：回滚指针。每次修改某行记录时，都会把undo日志地址赋值给roll_pointer隐藏列。

假设hero表中只有一行记录，当时插入的事务id为80。此时，该条记录的示例图如下： mvcc1 假设之后两个事务id分别为100、200的事务对这条记录进行UPDATE操作，操作流程如下： mvcc2 由于每次变动都会先把undo日志记录下来，并用roll_pointer指向undo日志地址。因此可以认为，对该条记录的修改日志串联起来就形成了一个版本链，版本链的头节点就是当前记录最新的值。如下： mvcc3

ReadView

如果数据库隔离级别是未提交读（READ UNCOMMITTED），那么读取版本链中最新版本的记录即可。如果是是串行化（SERIALIZABLE），事务之间是加锁执行的，不存在读不一致的问题。但是如果是已提交读（READ COMMITTED）或者可重复读（REPEATABLE READ），就需要遍历版本链中的每一条记录，判断该条记录是否对当前事务可见，直到找到为止(遍历完还没找到就说明记录不存在)。InnoDB通过ReadView实现了这个功能。ReadView中主要包含以下4个内容：

m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。
creator_trx_id：表示生成该ReadView事务的事务id。

有了ReadView之后，我们可以基于以下步骤判断某个版本的记录是否对当前事务可见。

如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值大于或等于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。READ COMMITTED在每次读取数据前都会生成一个ReadView，这样就能保证每次都能读到其它事务已提交的数据。REPEATABLE READ 只在第一次读取数据时生成一个ReadView，这样就能保证后续读取的结果完全一致。