07-07 17:09 湖南信息学院 Java 发布于湖南

关注

MySQL事务空间详解

1. 基本概念

1.1 事务空间的定义

事务空间是指MySQL数据库中，一个事务执行过程中所拥有的所有相关信息和上下文环境的集合。它不是MySQL官方术语，而是一个概念性术语，用于描述事务的隔离环境和执行上下文。

事务空间包含了事务执行所需的所有状态信息、资源引用和隔离机制所需的数据结构，是理解MySQL事务实现机制的重要概念。

1.2 事务空间的作用

事务空间的主要作用包括：

提供隔离环境：确保事务之间相互隔离，一个事务的操作不会影响其他事务
维护事务状态：记录事务的执行状态、持有的资源等信息
支持ACID特性：特别是隔离性(Isolation)和一致性(Consistency)的实现
实现并发控制：通过锁机制和MVCC(多版本并发控制)实现并发事务的管理

2. 事务空间的组成部分

事务空间由以下几个关键部分组成：

2.1 事务标识信息

事务ID (trx_id)：唯一标识每个事务的数字
事务状态：表示事务当前的执行状态，如活动、提交中、已提交、回滚中等
开始时间戳：事务开始执行的时间点

2.2 隔离相关信息

隔离级别设置：事务的隔离级别(READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE)
Read View (读视图)：定义哪些其他事务的修改对当前事务可见
MVCC相关信息：用于确定行版本可见性的数据结构

2.3 资源管理信息

Undo日志位置指针：指向事务的撤销日志记录
锁信息：事务持有的锁和等待的锁
已修改页面的跟踪信息：记录事务修改过的缓冲池页面

2.4 操作记录

事务内执行的操作日志：记录事务执行的SQL操作
保存点信息：事务内部的回滚点

3. 事务空间的存储位置

事务空间的信息分散存储在MySQL的多个位置：

3.1 内存中的事务对象

InnoDB维护一个事务系统，每个活动事务有一个内存中的事务对象
包含事务ID、状态、隔离级别等基本信息
在MySQL内部实现中，使用trx_t结构体表示

3.2 系统表空间

部分事务信息存储在系统表空间中
特别是在崩溃恢复时需要的持久化信息
包括事务系统页、回滚段头等

3.3 Undo表空间

存储事务的撤销日志记录
这些记录用于事务回滚和MVCC
在MySQL 8.0中，可以配置独立的Undo表空间

4. 事务空间与线程的比较

4.1 相似点

执行上下文
- 线程提供代码执行的上下文环境
- 事务空间提供事务执行的上下文环境
隔离性
- 线程有独立的栈空间，局部变量互不影响
- 事务空间提供事务隔离性，一个事务看不到其他未提交事务的修改
生命周期
- 线程有创建、运行、结束的生命周期
- 事务空间有开始、执行、提交/回滚的生命周期

4.2 重要区别

物理实现
- 线程是操作系统或JVM的实体，有独立的内存分配
- 事务空间是数据库的逻辑概念，不是独立的内存区域
资源访问
- 线程可以有私有内存，也可以访问共享内存
- 事务不复制数据页，总是访问共享的缓冲池
隔离实现
- 线程通过内存隔离和同步机制实现
- 事务通过MVCC和锁机制实现

4.3 MySQL中事务与线程的实际关系

在MySQL实现中：

连接与线程
- 每个客户端连接由一个服务器线程处理
- 这个线程负责执行该连接的所有SQL语句
线程与事务
- 一个线程在同一时间只能有一个活动事务
- 事务总是属于特定的线程
- 线程可以顺序执行多个事务，但不能并行
事务上下文
- 事务上下文存储在线程的内存空间中
- 这部分可以理解为"事务空间"

5. 事务访问缓冲池的机制

5.1 页面访问流程

事务需要访问数据时，首先查找缓冲池
如果页面在缓冲池中，直接访问
如果不在，从磁盘加载到缓冲池，然后访问
多个事务可以同时访问同一个页面

5.2 页面修改流程

事务修改数据前，先获取相应的锁(行锁或页锁)
记录原始数据到undo日志
直接在缓冲池的页面上修改数据
记录修改操作到redo日志
修改后的页面被标记为"脏页"

5.3 并发控制

读操作：通过MVCC实现非阻塞读
写操作：通过锁机制防止冲突
版本控制：不同事务可能看到同一页面上不同版本的行

6. MVCC实现机制

6.1 MVCC基本原理

多版本并发控制(MVCC)是InnoDB实现事务隔离的核心机制，它允许多个事务同时读取同一数据的不同版本，从而避免读-写冲突。

6.2 行记录的隐藏列

InnoDB的每一行记录中都包含以下隐藏列：

DB_TRX_ID：最后修改该行的事务ID
DB_ROLL_PTR：指向undo日志的指针，用于找到该行的历史版本
DB_ROW_ID：如果表没有主键，InnoDB会自动生成此ID

6.3 Read View

Read View是MVCC实现的核心数据结构，包含：

m_ids：活跃事务ID列表
m_low_limit_id：高水位，大于等于这个ID的事务均不可见
m_up_limit_id：低水位，小于这个ID的事务均可见
m_creator_trx_id：创建该Read View的事务ID

6.4 可见性判断

当事务读取一行记录时，InnoDB会根据以下规则判断该行的可见性：

如果记录的DB_TRX_ID小于m_up_limit_id，则该记录可见
如果记录的DB_TRX_ID大于等于m_low_limit_id，则该记录不可见
如果记录的DB_TRX_ID在m_up_limit_id和m_low_limit_id之间：
- 如果DB_TRX_ID在m_ids列表中，则该记录不可见
- 如果DB_TRX_ID不在m_ids列表中，则该记录可见

6.5 不同隔离级别下的Read View创建时机

READ UNCOMMITTED：不使用Read View
READ COMMITTED：每次读取数据前创建新的Read View
REPEATABLE READ：事务开始时创建Read View，整个事务期间使用同一个Read View
SERIALIZABLE：不使用MVCC，使用锁来实现隔离

7. 事务空间在MySQL内部实现中的表现

7.1 trx_t结构体

在InnoDB内部，事务由trx_t结构体表示，包含：

struct trx_t {
  trx_id_t id;                 /* 事务ID */
  trx_state_t state;           /* 事务状态 */
  ReadView *read_view;         /* 事务的读视图 */
  trx_lock_t lock;             /* 事务的锁信息 */
  trx_undo_t *undo_no;         /* 事务的undo日志号 */
  /* 其他字段... */
};

7.2 事务系统表

InnoDB维护事务系统表，可通过INFORMATION_SCHEMA查询：

INNODB_TRX：当前运行的所有事务
INNODB_LOCKS：当前的锁
INNODB_LOCK_WAITS：锁等待关系

7.3 事务生命周期管理

事务创建：执行BEGIN或START TRANSACTION时，MySQL创建新的事务空间
事务执行：执行SQL语句，修改数据，获取锁，生成undo日志等
事务提交：执行COMMIT时，将修改持久化，释放锁，清理事务空间
事务回滚：执行ROLLBACK时，应用undo日志，撤销修改，释放锁，清理事务空间

8. 隔离级别对事务空间行为的约束

隔离级别是约束事务空间行为的重要机制，它决定了一个事务如何看待其他事务的修改。

8.1 隔离级别的基本概念

MySQL支持四种隔离级别，从低到高分别是：

READ UNCOMMITTED：读未提交
READ COMMITTED：读已提交
REPEATABLE READ：可重复读（InnoDB默认级别）
SERIALIZABLE：串行化

隔离级别越高，一致性越好，但并发性能越低；隔离级别越低，并发性能越好，但可能出现数据不一致问题。

8.2 不同隔离级别下的事务行为

下面通过具体例子说明两个事务同时修改同一数据时，在不同隔离级别下会发生什么。

8.2.1 读未提交 (READ UNCOMMITTED)

特点：事务可以读取其他事务未提交的修改。

例子：

时间点1: T1开始事务
时间点2: T2开始事务
时间点3: T1执行 UPDATE users SET balance=balance-100 WHERE id=1 (余额变为900)
时间点4: T2执行 SELECT balance FROM users WHERE id=1 (读到余额为900)
时间点5: T1执行 ROLLBACK (余额恢复为1000)
时间点6: T2执行 UPDATE users SET balance=balance-200 WHERE id=1 (基于读到的900，更新为700)
时间点7: T2执行 COMMIT (最终余额变为700，而非预期的800)

结果：T2读取到了T1未提交的修改(脏读)，导致最终结果错误。

注意：在这个例子中，T1执行ROLLBACK是人为决定的，可能是因为业务逻辑错误、应用程序异常或显式回滚。这个例子主要是为了演示脏读问题可能导致的数据不一致。

8.2.2 读已提交 (READ COMMITTED)

特点：事务只能读取其他事务已提交的修改。

例子：

时间点1: T1开始事务
时间点2: T2开始事务
时间点3: T1执行 UPDATE users SET balance=balance-100 WHERE id=1 (余额变为900)
时间点4: T2执行 SELECT balance FROM users WHERE id=1 (读到余额为1000，因为T1未提交)
时间点5: T1执行 COMMIT (余额确认为900)
时间点6: T2再次执行 SELECT balance FROM users WHERE id=1 (读到余额为900，因为T1已提交)
时间点7: T2执行 UPDATE users SET balance=balance-200 WHERE id=1 (基于读到的900，更新为700)
时间点8: T2执行 COMMIT (最终余额为700)

结果：T2在同一事务中两次读取得到不同结果(不可重复读)，但避免了脏读。

8.2.3 可重复读 (REPEATABLE READ)

特点：事务在执行期间多次读取同一数据会得到相同结果。

例子：

时间点1: T1开始事务
时间点2: T2开始事务
时间点3: T1执行 UPDATE users SET balance=balance-100 WHERE id=1 (余额变为900)
时间点4: T2执行 SELECT balance FROM users WHERE id=1 (读到余额为1000，因为使用事务开始时的快照)
时间点5: T1执行 COMMIT (余额确认为900)
时间点6: T2再次执行 SELECT balance FROM users WHERE id=1 (仍读到余额为1000，保证可重复读)
时间点7: T2执行 UPDATE users SET balance=balance-200 WHERE id=1

在时间点7，MySQL的InnoDB会有两种可能的行为：

情况1 - 使用当前读：

时间点7: T2执行 UPDATE users SET balance=balance-200 WHERE id=1 (基于当前值900，更新为700)
时间点8: T2执行 COMMIT (最终余额为700)

情况2 - 发生写冲突：

时间点7: T2执行 UPDATE users SET balance=balance-200 WHERE id=1 (尝试基于快照值1000更新，但检测到行已被修改)
         系统抛出错误: "ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction"

结果：T2在同一事务中多次读取得到相同结果(可重复读)，但可能遇到写冲突。

8.2.4 串行化 (SERIALIZABLE)

特点：事务完全隔离，顺序执行。

例子：

时间点1: T1开始事务
时间点2: T2开始事务
时间点3: T1执行 SELECT balance FROM users WHERE id=1 FOR UPDATE (读到余额为1000并加锁)
时间点4: T2尝试执行 SELECT balance FROM users WHERE id=1 (被阻塞，等待T1释放锁)
时间点5: T1执行 UPDATE users SET balance=balance-100 WHERE id=1 (余额变为900)
时间点6: T1执行 COMMIT (余额确认为900，释放锁)
时间点7: T2继续执行之前被阻塞的查询 (读到余额为900)
时间点8: T2执行 UPDATE users SET balance=balance-200 WHERE id=1 (基于读到的900，更新为700)
时间点9: T2执行 COMMIT (最终余额为700)

结果：事务完全串行执行，避免了所有并发问题，但性能最低。

8.3 隔离级别对事务空间行为的具体约束

读未提交：
- 事务空间不使用Read View
- 直接读取缓冲池中的最新数据
- 不检查行记录的事务ID
读已提交：
- 每次读操作都创建新的Read View
- 只能看到已提交事务的修改
- 不同读操作之间可能看到不同的数据版本
可重复读：
- 事务开始时创建Read View，整个事务期间使用同一个Read View
- 保证同一事务内多次读取结果一致
- 写操作使用"当前读"，可能导致写冲突
串行化：
- 读操作也会获取共享锁(S锁)
- 写操作获取排他锁(X锁)
- 通过锁机制而非MVCC实现隔离