原理：深入理解MySQL数据库中MVCC与BufferPool缓存机制

一、MVCC机制

• MVCC(Multi Version Concurrency Control)，MySQL(默许)RR隔离级别就是通过该机制来保证的，对一行数据的读与写两个操作默许是不会通过加锁互斥来保证隔离性的
• 串行化隔离级别是为了保证较高的隔离性，是通过将所有操作加锁互斥来实现的
• MySQL在RC隔离级别和RR隔离级别下都实现了MVCC机制
• RC每次查询都会创建一个reade-view，而RR在创建完read-view以后，在不提交事务之前，每次查询或者第一次创建的read-view

undo日志版本链与read-view机制

• undo日志版本链是指一行数据被多个事务一次修改后，当每一个事务修改完以后，MySQL会保存修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把只写undo日志串连起来构成一个历史记录版本链.
• RR隔离级别，当事务开启，履行任何SQL时会生成当前事务的read-view一致性视图，该视图在事务结束之前都不会变化(如果是RC隔离界别在每次履行查询SQL时都会重新生成最新的read-view)，这个视图由履行查询时所有未提交的事务id数组(数组里最小的id为min_id)和已创建的最大事务id(max_id)组成，事务里任何SQL查询结果需要从对应版本链里的最新数据开始逐条跟read-view作比对，从而得到终究的结果

版本链比对规则

• 如果row的trx_id落在绿色部份(trx < min_id)，表示这个版本是已提交的事务生成的，这个数据是可见的
• 如果row的trx_id落在红色部份(trx > max_id)，表示这个版本是由将来启动的(未开始)事务生成的，是不可见的(若row的trx_id就是当前自己的事务是可见的)
• 如果 row 的 trx_id 落在黄色部份(min_id <= trx_id <= max_id),那就包括两种情况
  • 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的不可见(若 row 的 trx_id 就是当前自己的事务是可见的)
  • 若 row 的 trx_id 不在视图数组中，表示这个版本是已提交了的事务生成的可见

二、BufferPool机制

InnoDB履行的BufferPool缓存机制：

InnoDB的SQL履行流程：

• 当客户端履行一条修改的SQL，需要经过Server层，再调用具体的履行引擎
• 加载数据页，把需要修改数据所在的数据页，缓存到BufferPool
• 修改前写undo日志，记录更改前数据，如果事务履行失败，使用undo日志进行数据回滚
• 更新BufferPool中的数据
• 准备提交事务写redo日志，保存操作记录。redo日志用来恢复已提交事务的BufferPool
• 准备提交事务写binlog日志，保存操作记录。binlog日志用来恢复磁盘数据
• 事务提交完成，此时binlog日志写入成功，并且在redo日志中记录了commit标记。事务提交完成后binlog日志和redo日志数据保持一致
• 数据持久化，IO线程不定期把BufferPool中的数据随机写入到磁盘，完成持久化

三、总结

MVCC实现机制(为何同一个事务第一次查询出来以后，就算其它事务把新数据修改了，当前事务或者看到之前的数据)

• 它内部实际有个undo日志版本链，然后在事务第一次查询的时候，它会生成一个read-view一致性视图，然后我们后面所有查询的数据都会根据我们的那个undo日志版本链去跟我们当前的read-view里面依照一定的规则逐行去比对查找对应的数据

BufferPool机制：

• 数据库的增删改查都是直接操作BufferPool的，当我们履行一条修改的SQL经历过Server层以后会调用具体的履行引擎，然后将相关的数据页加载到BufferPool中，修改前写undo日志，记录修改前的数据为了方便事务失败以后的回滚，然后更新BufferPool，准备提交事务写redo日志保存操作记录，由于如果MySQL宕机了会从redo日志中将数据恢复到BufferPool中，然后会写binlog日志，保存操作记录，由于当我们删除数据库跑路时，binlog是用来恢复磁盘数据的，事务提交完成后，binlog日志写入成功，并且在redo日志记录提交标记，此时redo日志和binlog日志数据一致，而redo日志采取顺序IO写入，这样效力堪比内存操作。对数据持久化，InnoDB会有个后台线程定时去将缓存刷到磁盘里

为何MySQL不能直接更新磁盘上的数据而是设置了这么一套复杂的机制来履行SQL

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

到此这篇关于原理：深入理解MySQL数据库中MVCC与BufferPool缓存机制的文章就介绍到这了,更多相关MVCC与BufferPool缓存机制内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！