MySQL事务原理深度剖析：MVCC与Read View详解

创作时间:

作者:

@小白创作中心

MySQL事务原理深度剖析：MVCC与Read View详解

引用

CSDN

https://m.blog.csdn.net/web15117360223/article/details/145658131

MySQL事务处理机制是数据库管理中的核心内容之一，其中MVCC（多版本并发控制）和Read View是实现高并发读写操作的关键技术。本文将深入解析MVCC和Read View的工作原理，以及它们在不同隔离级别下的表现，帮助读者全面理解MySQL事务处理机制。

事务隔离级别回顾

在深入讲解MVCC和Read View之前，我们先回顾一下事务的四种隔离级别及其可能引发的问题：

脏读：一个事务读到另一个事务未提交的数据。
不可重复读：一个事务在两次读取之间，数据被另一个事务修改。
幻读：一个事务在两次读取之间，数据行被另一个事务插入或删除。
读未提交：允许脏读、不可重复读和幻读。
读已提交：解决脏读问题，但存在不可重复读和幻读。
可重复读：解决脏读和不可重复读，某些数据库可能仍有幻读问题（MySQL已解决）。
串行化：通过加锁避免所有并发问题，但牺牲了并发性能。

一致性与并发控制

事务执行的结果必须使数据库从一个一致性状态变到另一个一致性状态。一致性是通过原子性保证的，即事务要么全部完成，要么完全不执行。

在并发控制方面，主要有三种并发方式：

读读并发：不存在任何问题，不需要并发控制。
读写并发：可能造成事务隔离性问题，如脏读、幻读、不可重复读。
写写并发：可能造成更新丢失问题。

MVCC基础：隐藏字段

MySQL在表中会自动添加三个隐藏字段：

DB_TRX_ID：记录最后修改该行数据的事务ID。
DB_ROLL_PTR：指向undo日志中的历史版本。
DB_ROW_ID：隐藏的自增ID，如果没有主键，InnoDB会自动以DB_ROW_ID产生聚簇索引。

Undo日志与版本链

Undo日志是MySQL中的一段内存缓冲区，用于记录事务的回滚操作。当一个事务需要修改数据时，会先将数据复制到undo日志中，然后进行修改。这样，如果需要回滚，可以从undo日志中恢复数据。

例如，假设有一行数据：

id	name	age
1	张三	25

事务10想要将名字从"张三"改为"李四"：

将数据加锁。
将数据复制到undo日志中。
修改现存数据：name改为"李四"，事务ID改为10，回滚指针指向undo日志中的数据。
commit，释放锁。

如果事务11随后想要将age修改为28：

将数据加锁。
将数据复制到undo日志中。
修改现存数据：age改为28，事务ID改为11，回滚指针指向undo日志中的数据。
commit，释放锁。

这样就形成了一个版本链：

MVCC多版本控制

MVCC通过版本链实现多版本控制，每个版本的数据称为快照。Undo log管理的是一个事务内所形成的版本链条。对于insert操作，虽然没有版本链，但insert对应的数据也要放到undo log里面。commit后，insert对应的版本链可以被清空，而update和delete的版本链可能需要保留，因为可能有其他事务在访问这条记录。

Read View

Read View是事务进行快照读操作时生成的读视图，记录系统当前活跃事务的ID。Read View是一个类，与事务的关系类似于进程地址空间和PCB。其结构如下：

class Readview
{
private:
    trx_id_t m_low_limit_id;  // 高水位，大于等于这个ID的事务均不可见。
    trx_id_t m_up_limit_id;  // 低水位，小于这个ID的事务均可见。
    trx_id_t m_creator_trx_id;     // 创建该Read view的事务ID。    
    ids_t m_ids; // 创建视图时的活跃事务id列表。
    trx_id_t m_low_limit_no; 
    bool m_closed;  // 视图是否关闭
    //....省略       
};

Read View的两个关键水位线是m_low_limit_id和m_up_limit_id。m_ids记录创建视图时的活跃事务ID列表。当进行快照读时，会根据这些信息判断当前事务能够看到哪个版本的数据。