MySQL事务原理以及MVCC详解
在MySQL中，最总要的几部分莫过于事务了，那么事务的执行也会伴随着并发事务的问题，MySQL是如何解决并发事务的问题呢
事务
事务（Transaction）是数据库管理系统执行过程中的一个逻辑单位，由一组不可分割的数据库操作序列组成。举个现实世界的例子：当你在ATM机转账时，系统需要同时完成「转出账户扣款」和「转入账户加款」两个操作，这两个操作必须作为一个整体执行
事务 是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败
ACID
事务有四大特性：
- 原子性(Atomicity):事务是不可分割的最小操作单元，要么全部成功，要么全部失败
- 一致性(Consistency):事务完成时，必须使所有的数据都保持一致状态
- 隔离性(lsolation):数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
- 持久性(Durability):事务一旦提交或回滚，它对数据库中的数据的改变就是永久的
事务并发
事务与事务之间如果同时操作某一张表或某一个数据库就可能会引发一些并发事务问题：
- **脏读：**一个事务读到另外一个事务还没有提交的数据
- **不可重复读：**一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读
- **幻读：**一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了"幻影”
隔离级别
MySQL定义了四种事务的隔离级别用来控制事务与事务之间的可见性影响：
| 隔离级别 | 脏读（Dirty Read） | 不可重复读（Non-Repeatable Read） | 幻读（Phantom Read） | 实现机制 | 典型应用场景 |
|---|---|---|---|---|---|
| 读未提交 (RU) | ✅ 允许 | ✅ 允许 | ✅ 允许 | 直接读取内存页最新数据 | 统计类查询（不要求强一致性） |
| 读已提交 (RC) | ❌ 禁止 | ✅ 允许 | ✅ 允许 | 每次查询生成新ReadView（MVCC） | 高并发OLTP系统（默认隔离级别） |
| 可重复读 (RR) | ❌ 禁止 | ❌ 禁止 | ❌ 禁止* | 事务开始时生成ReadView（MVCC+间隙锁） | MySQL默认（平衡一致性与性能） |
| 串行化 (Serializable) | ❌ 禁止 | ❌ 禁止 | ❌ 禁止 | 完全锁表（读写互斥） | 金融交易等强一致性场景 |
注：MySQL在RR级别通过Next-Key Lock（间隙锁+行锁）避免幻读，但标准SQL规范中RR允许幻读
这里的实现机制此时你可能还不太明白，下面会有讲解
事务原理
上面提到了事务的四大特性ACID，我们逐一来学习他们的实现原理
日志文件
MySQL中包含有两种日志文件，分别是：
- redo log
- undo log
其中redo log保证了事务的持久性、而undo log则保证了事务的原子性，二者共同保证了事务的一致性
redo log
重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性
该日志文件由两部分组成：重做日志缓冲(redolog buffer)以及重做日志文件(redolog file)，前者是在内存中，后者在磁盘中，当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发生错误时，进行数据恢复使用
undo log
回滚日志，用于记录数据被修改前的信息，作用包含两个:提供回滚 和 MVCC(多版本并发控制)
undo log和redo log记录物理日志不一样，它是逻辑日志，可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录，当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
- Undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC
- Undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的 rollback segment 回滚段中，内部包含1024个undo log segment
而事务隔离性的实现，是基于锁机制和MVCC来实现的
MVCC
全称Multi-Version Concurrency Control，即多版本并发控制，在学习它之前，我们需要先了解两个概念
- 当前读：读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如:select… lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读
- 快照读：简单的select(不加锁)就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读
MVCC指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undol0g日志、readView
三个隐式字段
当我们创建一个数据库表的时候，数据库除了我们自己定义的字段之外，还会为我们生成三个隐式字段：
| 隐式字段 | 含义 |
|---|---|
| DB_TRX_ID | 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID |
| DB_ROLL_PTR | 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本 |
| DB_ROW_ID | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段 |
Undo Log版本链
上面我们已经提到了回滚日志undo log，其中保存了被修改的数据行，每个被修改的数据行都会通过隐藏的指针字段，将不同事务产生的修改版本按时间顺序串联成链表，形成数据的历史版本回溯链
其会配合被操作的数据行中的隐藏字段DB_ROLL_PTR找到需要回滚的版本：
那么在返回数据时到底返回哪个版本的数据呢？这需要由readView来控制
readView
ReadView(读视图)是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务(未提交的)id
每个ReadView包含三个关键要素：
- 活跃事务ID列表：保存了所有的当前活跃事务（未提交事务），每个事务都有对应的ID，并且ID是自增的
- 高水位线就是当前最大事务ID+1
- 低水位线是最小活跃事务ID
- 创建者事务ID是生成当前readView的事务ID
刚刚提到在回滚日志undo log中保存有很多版本的数据，那么在返回数据的时候究竟返回哪个版本的数据就是由readView来控制
给定数据行的DB_TRX_ID（修改该行的事务ID），通过以下流程判断可见性
判断逻辑详解：
- 低水位检查：如果数据版本事务ID < up_limit_id，说明在ReadView创建前已提交，可见
- 高水位检查：如果数据版本事务ID ≥ low_limit_id，说明在ReadView创建后修改，不可见
- 活跃事务检查：如果数据版本事务ID在活跃事务列表中，说明未提交，不可见
- 默认可见：通过前三关则可见
如果经过检查数据行中的隐式字段DB_TRX_ID与readView对比后，找到对应的可见版本并返回，如果当前DB_TRX_ID指向的事务版本不可见，则根据Undo Log版本链找他的下一个版本，直到能够返回可见数据
不同的隔离级别，生成Readview的时机不同:
READ COMMITTED：在事务中每一次执行快照读时生成ReadView
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView
因此，在RR可重复读的事务隔离级别中，在第一次读数据就生成了ReadView，并且第二次读数据沿用这个ReadView，通过这种方式可以防止两次读取的数据不一致，从而防止了不可重复读
