MySQL——MVCC机制与BufferPool缓存机制

前言

以下讲解均基于InnoDB存储引擎

MVCC多版本并发控制机制

MVCC（Multi-Version Concurrency Control）机制对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。另外，MySQL在读已提交和可重复读隔离级别下都实现了MVCC机制。

undo日志版本链与read view机制

在讲解MVCC之前先来了解一下这两个知识点
undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，MySQL会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链，如下图

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

版本链对比规则

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的。

BufferPool缓存机制

一张图足以说明

为什么MySQL不能够直接更新磁盘上的数据而是设置一套这么复杂的机制来执行sql？
因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据，性能可能相当差。由于磁盘随机读写的性能非常差，所以直接更新磁盘文件是不能让数据库抗住很高的并发。MySQL这套机制看起来很复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件，正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几千的读写请求。

最后

以上就是关于MySQL索引的知识点，欢迎各位大佬指出错误之处，共同学习，共同进步！