当前位置：首页 > article >正文

mysql mvvc 实现方案

article 2025/10/27 4:36:45

Mysql 事务隔离级别

并发问题

mysql中事务并发时，会产生的问题如下

脏读:

读到了其他事务中，暂未提交的数据

脏读 (Dirty Read) 是数据库事务隔离级别中最低的一种隔离级别 (READ UNCOMMITTED) 下可能出现的一种并发问题。它指的是一个事务读取了另一个事务尚未提交 (未持久化) 的数据。如果后续未提交的事务回滚了，那么第一个事务读取到的数据就是无效的、不正确的，相当于读取了“脏”数据。

幻读:

同一个事务中，相同的查询，前后记录条数不一致

幻读 (Phantom Read) 是数据库事务隔离级别下可能出现的一种并发问题。它指的是在一个事务内，第一次读取符合某些条件的数据，第二次读取同一范围的数据时，却发现了第一次查询中不存在的新数据 (幻影行)，好像凭空出现了一样。这是因为在两次读取之间，另一个事务插入了满足查询条件的新数据并提交了
常见问题：
事务1：读取A表，判断id=1是否存在，发现不存在，（此时事务2：写入A表，id=1），事务1：写入A表id=1报错主键冲突

不可重复读:

同一个事务中，相同的查询，相同记录，前后结果不一致

不可重复读 (Non-repeatable Read) 是数据库事务隔离级别下可能出现的一种并发问题。它指的是在一个事务内，两次读取同一行数据，得到的结果不一致。这是因为在两次读取之间，另一个事务修改了该数据并提交了

隔离级别

RU:

RU(READ UNCOMMITTED) 不管任何并发性问题，上述问题一个没解决

RC:

RC (READ COMMITTED) 读已提交，只解决了脏读

RR:

RR (REPEATABLE READ) 可重复读，它保证在同一个事务中，多次读取同一数据时，数据值是一致的，但可能存在“幻读”问题。

SERIALIZABLE

SERIALIZABLE 顺序读，最严格事务机制，事务串行执行，上述问题都可以解决，常见于金融系统

实现方案：MVCC

多版本并发控制 (Multi-Version Concurrency Control, MVCC) ，上述隔离级别的实现方案

UNDO LOG:

每个mysql表都有两个隐藏"字段"，trx_id（修改该数据的事务的事务编号）,roll_pointer（修改该数据之前数据视图指针），这两个关键字段是在事务执行过程中修改数据时立即更新的，而不是在事务提交后

INSERT 操作: 当一个事务插入一条新记录时，InnoDB 会立即将该记录的 row.trx_id 设置为当前事务的 trx_id。这意味着从那一刻起，InnoDB 就知道这条记录是由哪个事务创建的。
UPDATE 操作: 当一个事务更新一条现有记录时，InnoDB 不会直接修改原始记录。而是创建一个新的数据版本，并将 row.trx_id 设置为当前事务的 trx_id。原始记录会被保留，并标记其 row_del_trx_id (如果需要，取决于更新的性质)。这就是 MVCC 的核心思想：保留多个版本的数据，以便不同的事务可以看到不同时间点的数据状态。
DELETE 操作: 虽然是删除操作，但 InnoDB 实际上只是将该记录的 row_del_trx_id 设置为当前事务的 trx_id，标记为已删除。数据的物理删除可能会在以后的某个时间进行 (例如，通过 purge 线程)。

在这里插入图片描述

READ VIEW:

read view 数据版本管理重要参数封装，有四个关键参数

m_ids : 生成Read View时，同时运行的事务编号List (不包括当前事务自身)
min_limit_id :表示在生成 Read View 时，当前系统中活跃的读写事务中最小的事务 id，即 m_ids 中的最小值。
max_limit_id :表示生成 Read View 时，系统中应该分配给下一个事务的 id 值，即max(m_ids)+1。
creator_trx_id : 创建当前 Read View 的事务 ID (也就是当前事务的 ID)

如上图
m_ids：[100,103,104]
min_limit_id: 100
max_limit_id: 105
creator_trx_id: 102
这里会有个疑问，102事务启动时，103、104肯定还没启动或同时启动，此时102创建的m_ids中怎么可能包含103、104？

答：102启动立刻分配trx_id=102，但是从102启动到生成read_view 是有一段时间间隔的
T0: 事务 102 开始，trx_id 102被分配。
T1: 事务 102 正在创建 Read View。
T2: 事务 103 开始，trx_id 103 被分配。
T3: 事务 104 开始，trx_id 104 被分配。
T5: 事务 102 完成 Read View 的创建。

RR实现方式

沿用上图readview

102事务进行查询时，row.trx_id 可能出现如下情况

如果数据事务 ID trx_id < min_limit_id ，表明生成该版本的事务在生成 ReadView前，已经提交(因为事务 ID 的递增的)，所以该版本可以被当前事务访问。
如果 trx_id>= max_limit_id ，表明生成该版本的事务在生成 Read View 后才生成，所以该版本不可以被当前事务访问。
如果 min_limit_id =<trx_id< max_limit_id ,需要分 3 种情况讨论
- 如果 m_ids 包含 trx_id ,则代表 Read View 生成时刻，这个事务还未提交，但是如果数据的 trx_id 等于 creator_trx_id 的话，表明数据是自己生成的，因此是可见的。
- 如果 m_ids 包含 trx_id ，并且 trx_id 不等于 creator_trx_id ，则ReadView 生成时，事务未提交，并且不是自己生产的，所以当前事务也是看不见的；
- 如果 m_ids 不包含 trx_id ，则说明你这个事务在 Read View 生成之前就已经提交了，修改的结果，当前事务是能看见的

如果某一版本不可见，就会根据undo_log版本链向后查询（101不行看100，100不行看99），直到找到可见版本，然后返回

举例说明：
read_view
m_ids：[101,102,103,104]
min_limit_id: 100
max_limit_id: 105
creator_trx_id: 1021、eg: row.trx_id <= 99
102查询时，事务<=99版本不处于m_ids中，是历史版本，因此可见2、eg: row.trx_id = 100
102查询时，事务100版本处于m_ids中是当前版本，不是自己的，因此不可见3、eg: row.trx_id = 101
102查询时，事务101版本不处于m_ids中，是历史版本，因此可见3、eg: row.trx_id = 102
102查询时，事务102版本是自己的，因此可见4、eg: row.trx_id = 103
102查询时，事务103版本处于m_ids中，是当前版本，不是自己的，因此不可见5、eg: row.trx_id = 104
102查询时，事务104版本处于m_ids中，是当前版本，不是自己的，因此不可见6、eg: row.trx_id >= 105
102查询时，事务>=105版本不处于m_ids中，是未来版本，因此不可见