最新MySQL高级（MVCC实现原理，日志系统）篇，java面试题刷题-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84557750/article/details/138835207

最后

权威指南-第一本Docker书

引领完成Docker的安装、部署、管理和扩展，让其经历从测试到生产的整个开发生命周期，深入了解Docker适用于什么场景。并且这本Docker的学习权威指南介绍了其组件的基础知识，然后用Docker构建容器和服务来完成各种任务：利用Docker为新项目建立测试环境，演示如何使用持续集成的工作流集成Docker，如何构建应用程序服务和平台，如何使用Docker的API，如何扩展Docker。

总共包含了：简介、安装Docker、Docker入门、使用Docker镜像和仓库、在测试中使用Docker、使用Docker构建服务、使用Fig编配Docke、使用Docker API、获得帮助和对Docker进行改进等9个章节的知识。

关于阿里内部都在强烈推荐使用的“K8S+Docker学习指南”—《深入浅出Kubernetes：理论+实战》、《权威指南-第一本Docker书》，看完之后两个字形容，爱了爱了！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

4、日志的开启

redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。

六、MySQL事务

在MySQL基础篇，已经陈述事务相关的基本内容，不再赘述！

读未提交（READ UNCOMMITTED）：一个事务还没提交时，它做的变更就能被别的事务看到。
读提交（READ COMMITTED）：一个事务提交之后，它做的变更才会被其他事务看到。
可重复读（REPEATABLE READ）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行化（SERIALIZABLE）：对于同一行记录，“写”会加“写锁”，“读”会加“读锁”，当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

以后我们会把读提交简称为RC，可重复读简称为RR

一般我们面临的并发场景就是如下三种

读读并发：不会存在任何线程安全问题，也不需要并发控制
读写并发：会有线程安全问题，因此需要加锁，但是加锁效率太低，故引入**MVCC(锁)进行并发控制**
写写并发：会有线程安全问题，更新丢失问题

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制，解决并发读写问题

1、MVCC实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志，Read View 来实现的

在学习MVCC多版本并发控制之前，我们必须先了解一下如下知识！

1、快照读和当前读

当前读 ：读取的是MySQL对应数据的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

select lock in share mode(共享锁); select for update ; update ; insert ;delete(排他锁) /*这些操作都是一种当前读

快照读 ：读取的是MySQL对应数据的历史版本

select /*仅这一个操作时快照读

MVCC多版本控制指的是维持一个数据的多个版本，使得读写操作没有冲突，快照读是MySQL为了实现MVCC的一个非阻塞读功能

实现原理

2、隐藏字段

隐藏字段是不可见的，除非翻阅源码；

插入和修改测试

这里的undo log就是上述日志中InnoDB自带的另一种日志，保存的是历史版本的数据，用以回滚

事务3修改name = lisi

我们发现，unlog当中旧的版本数据形成了一个链表，链表首部存储的是最新的旧纪录，链表尾部存放的是最旧的旧纪录

undolog不会无限膨胀下去，会存在一个后台线程，purge线程，当发现当前记录不需要回滚且不需要参与MVCC的时候，就会把数据清

理掉

3、readview

当事务在进行快照读的时候，会生成一个读视图来进行可见性判断，可见性判断是由可见性算法来确定（详聊可见性算法）

1、我们先看一个现象，如下我们两个会话执行类似的操作产生的结果（隔离界别：RR）

我们可以看到，事务2修改并提交的数据事务1中是可以看到的！

当我们再次进行如图测试，却的查不到我们的事务2修改并提交的数据，这是为什么？

2、操作统计

我们看到第二次操作只是比第一次操作多执行了1次select操作，这是为什么呢？

3、原理分析

让我们再次重温这句话：当事务在进行快照读的时候，会生成一个读视图来进行可见性判断，可见性判断是由可见性算法来确定！

而图中我们的select就恰恰就是快照读的唯一操作，所以会生成一致性读视图即consistent read view，进行可见性判，来判断事务1能否

看到事务2修改，且已经提交的内容！

1、首先我们可见性视图有如下几个字段，所以生成可见性视图会对如下字段进行填充

2、根据第一次操作表进行填充

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nrszAq09-1639583184050)(MySQL笔记（高级篇）.assets/image-20211215222903695.png)]

DB_TRX_ID：是我们上述表中的隐藏字段，表示的是最近修改的事务id
右侧就是我们的可见性

有了上述的内容，我们通过可见性算法对致性视图进行判断，得出结论：这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的。

因此，我们的操作1（图1）的操作得以解释！

3、根据第二次的操作，对表进行填充

这次我们采取倒推的方式

我们的操作2进行了2次select操作，第一次select操作进行快照读的时候生成了一个一致性视图如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vBID3SyW-1639583184050)(MySQL笔记（高级篇）.assets/image-20211215223830349.png)]

此时还未进行update操作，所以是读不到的，（注意：DB_TRX_ID是不属于ReadView的字段的，属于隐藏字段！）

接下来当我们执行完update，并且提交的时候进行select操作，会生成一个新一致性视图，但是从3行开始的操作都是一致的，生成的一致性视图也应该是与操作2的一致的呀，按理说我们应该也会生成如下的可见性视图呀！

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mSjqmQnJ-1639583184050)(MySQL笔记（高级篇）.assets/image-20211215223203429.png)]

但是我们如果是如下视图，经过可见性算法，我们应该可以看到数据的呀，所以得出结论：第二次select并未创建新的视图

总结：能否看到修改的数据取决于可见性算法，可见性算法比较的时候取决于readview中的结果值

结论

最后：学习总结——MyBtis知识脑图（纯手绘xmind文档）

学完之后，若是想验收效果如何，其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图，这样也可方便后续的复习，且都是自己的理解，相信随便瞟几眼就能迅速过完整个知识，脑补回来。下方即为我手绘的MyBtis知识脑图，由于是xmind文件，不好上传，所以小编将其以图片形式导出来传在此处，细节方面不是特别清晰。但可给感兴趣的朋友提供完整的MyBtis知识脑图原件（包括上方的面试解析xmind文档）