mysql-MVCC多版本并发版本控制和bufferPool缓存机制

目录

1.MVCC多版本并发控制

1.1 undo日志版本链

1.2 readview一致性视图

2.bufferPool缓存机制

---

书接上回：CSDN

1.MVCC多版本并发控制

mvcc(muti version Concurrent Control)多版本并发控制是mysql在可重复读和读已提交级别下的一种保证事物隔离性的机制。

面试大厂考点，不用解释特别清楚，大概讲解即可。

        mvcc内有两个重点概念：undo日志版本链(决定是否能查找到对应数据)和read view一致性视图(决定是否可见)。每次开启事物begin命令时mysql都会生成一个临时事物id，当执行具体sql时会生成真正的事物id，mysql会通过这个事物id去undo日志版本链中比对，并通过对readview生成的数组中比对最终找到当前事物数据。

1.1 undo日志版本链

undo日志版本链中有一列数据+两个隐藏字段trx_id（事物id）和回滚指针(roll_pointer)组成。指针指向上一个版本中的数据。

undo日志版本链比对规则：

1. 当前事物id<min_trx_id,代表为已提交事物，可见。

2. min_trx_id<=当前事物id<=max_trx_id，代表可能有未提交和已提交事物，可能可见也可能不可见。可见对应已提交事物，不可见对应未提交事物。

3. 当前事物id>max_trx_id，代表为未开始事物，不可见。

 

1.2 readview一致性视图

readview一致性视图在可重复读和读已提交下隔离级别下有个区别，这个区别导致了是否会有不可重复读的问题:可重复读在查询时生成的readview数组是固定的，第二次查询readview还是原来的，但是读已提交级别下每次查询都会去数据库里重复查询生成一个新的readview数组，这样原来的数据就是不可重复读了。

reaview里面分为三个特殊的区间。通过跟三个区间进行比对并跟undo日志版本链比对最终确定找到对应的数据。

1. 已提交事物数组(trx_id<min_tx_id)

2. 未提交和已提交事物数组(min_tx_id<trx_id<max_tx_id分为两种情况,第一种，trx_id在这个区间内的，代表未提交事物，不可见；第二种,trx_id在已提交事物数据内的代表已提交事物，可见)

3. 未开始事物数组(trx_id>max_tx_id)

2.bufferPool缓存机制

undolog:记录了增删改操作，主要用于删库以后的数据恢复使用

redolog:主要用来在系统泵机情况下恢复bufferpool内存里的数据

binlog:主要用来恢复磁盘上的数据

bufferPool缓存机制其实是数据库引擎层里面的东西，这个部分应该接着我开头的博客看一下。其中有几个对象概念：

server层(一个)：binlog日志

数据库引擎(对应表，有多个):buffer pool,undo log buffer,redolog日志，undolog日志，磁盘文件(ibd）大致流程分为以下几步：

1. 将磁盘文件ibd文件中脚本查询到的数据以多页的形式加载到bufferPool中

2. 将旧数据更新到undolog日志中，用于回滚数据

3. 执行器更新内存数据

4. 更新redolog日志到redolog buffer中

5. 准备提交事物，执行器将undo log数据写入到redolog日志文件中，如果系统宕机，数据库引擎可以从redolog日志中将数据恢复数据重新加载到bufferPool中。

6. 执行器提交事物将日志写入到binlog中

7. 提交commit标记，保证binlog日志与undolog日志数据的一致性。

不知道为啥其他人喜欢说什么idb，有图为证

mysql搞这么长一串一个重要的原因就是因为内存中的数据写入较快，而且写入日志文件中是以顺序写入，而对磁盘读写是随机读写，效率上远远小于内存。