MySQL之MVCC机制

╰+攻爆jí腚メ 2022-12-26 09:16 160阅读 0赞

## 1. MVCC概念 ##

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

在Mysql的InnoDB引擎中就是指在**已提交读**(READ COMMITTD)和**可重复读**(REPEATABLE READ)这两种隔离级别下的事务对于SELECT操作会访问版本链中的记录的过程。

这就使得别的事务可以修改这条记录，因为每次修改都会在版本链中记录。SELECT可以去版本链中拿记录，这就实现了读-写，写-读的并发执行，提升了系统的性能。

简单来说，即使有读写冲突时，也能做到不加锁，非阻塞并发读

## 2. 实现原理：undo日志版本链与read view机制 ##

#### 2.1 undo日志版本链 ####

undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段 **trx\_id**（记录创建这条记录/最后一次修改该记录的事务ID） 和**roll\_pointer**（回滚指针，指向这条记录的上一个版本，存储于rollback segment里）把这些undo日志串联起来形成一个历史记录版本链。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70]

#### 2.2 read view机制 ####

在**可重复读隔离级别**，当事务开启，执行任何查询sql时会生成当前事务的**一致性视图read-view**，该视图在事务结束之前都不会变化(**如果是读已提交隔离级别在每次执行查询sql时都会重新生成**)，这个视图由执行查询时所有**未提交事务id数组**（数组里最小的id为min\_id）和**已创建的最大事务id**（max\_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的**快照结果**。

**名词解析：**

*  **当前读**：像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁
 *  **快照读**：像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

**流程解析：**  
活跃事务（未提交事务）：200,100  
已提价事务：300

read view：\[活跃事务\] 已创建的最大事务id ===》 \[100,200\] 300

此时另一个事务发起了select 语句要查询id为1的记录，那此时生成的ReadView 列表只有\[100,200\]

在版本链去找，先找最近的，即trx\_id是200,也就是name为" lilei4 "的那条记录，通过比对规则，发现在列表内，所以不能访问

name为" lilei3 "的那条记录同理也不能访问

name为" lilei1 "的那条记录同理也不能访问

继续往下找，找到trx\_id是300,也就是name为" lilei300 "的那条记录，发现trx\_id=300，落在中间的黄色区域，且不在 \[100,200\] 的数组中，所以数据可以访问。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70 1][]

**版本链比对规则：**

1.  如果 row 的 trx\_id 落在绿色部分( trx\_id<min\_id )，表示这个版本是已提交的事务生成的，表示这个数据是可见的
2.  如果 row 的 trx\_id 落在红色部分( trx\_id>max\_id )，表示这个版本是由将来启动的事务生成的，表示是不可见的(若 row 的 trx\_id 就是当前自己的事务是可见的）
3.  如果 row 的 trx\_id 落在黄色部分(min\_id <=trx\_id<= max\_id)，那就包括两种情况  
    若 row 的 trx\_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx\_id 就是当前自己的事务是可见的)  
    若 row 的 trx\_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见

对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx\_id修改成删除操作的 trx\_id，同时在该条记录的头信息（record header）里的（deleted\_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete\_flag标记位为true，意味着记录已被删除，则不返回数据

**注意：** begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB表的语句， 事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的

#### 2.3 总结 ####

MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据

## 3.Innodb引擎SQL执行的BufferPool缓存机制 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center]  
**使用BufferPool而不是直接更新磁盘上的数据的原因**：

因为磁盘随机读写的性能是非常差的，且并发也比较差

如果来一个请求就直接对磁盘文件进行随机读写，系统的效率也会相当低下

BufferPool的整套机制可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性

更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。 正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70]: /images/20221120/226cfb5225dd4fb4a06d3e50483a0905.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70 1]: /images/20221120/d9010ba755684ae394f2a3c3c20e1f8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/cdfda3d3cfe448998778280002a53cac.png