Read uncommitted
未提交读，这个级别在读的过程中不会加任何锁，只在写请求时加锁，所以写操作在读的过程中修改数据，就会造成脏读。也自然会产生不可重复读和幻读。
Read committed
已提交读，与未提交读一样也是读不加锁，写加锁。不一样的是利用了 MVCC 机制避免了脏读的问题，同样会有不可重复读和幻读的问题。关于 MVCC 我们后面会详细说。
Repeatable read
MySQL 默认的隔离级别，在这个级别 MySQL利用两种方式解决问题
- 读写锁 读读并行时加读锁，读读是共享锁的。 只要有写请求就加写锁，这样读写是串行的。 读取数据时加锁，其它事务无法修改这些数据。所以不会产生不可重复读。 修改删除数据时也要加锁，其它事务无法读取这些数据，所以不会产生脏读。 第一种方式就是我们常说的 “悲观锁”，数据在整个事务处理过程中处于锁定状态，比较保守，性能开销比较大。
- MVCC （后面讲）
此外还利用了Next-Key锁 在一定程度上解决了幻读的问题。关于这个我们后面再说。
Serializable
在该隔离级别下事务都是串行顺序执行的。 如果禁用了自动提交，则 InnoDB 会将所有普通的 SELECT 语句隐式转换为 SELECT … LOCK IN SHARE MODE。即给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。
MVCC
“
Multiversion concurrency control (MCC or MVCC), is a concurrency control method commonly used by database management systems to provide concurrent access to the database and in programming languages to implement transactional memory
”
翻译过来就是：多版本并发控制（MCC或MVCC）是一种并发控制方法，通常被数据库管理系统用来提供对数据库的并发访问，并以编程语言来实现事务存储。
简单来说就是数据库用来控制并发的一种方法。每个数据库对于 MVCC 的实现可能不一样。
以我们常用的 MySQL 来说，MySQL 的 InnoDB 引擎实现了 MVCC 。
MVCC 能解决什么问题
从上面的定义我们能看出，MVCC 主要解决事务并发时数据一致性的问题
InnoDB 是如何实现的 MVCC
下面这个图来自《高性能MySQL》(第3版)
这本书写的很好，翻译的也不错，我对于 MySQL 最初的系统性认识也是因为读了这本书，然而在对于 MVCC 是如何实现的讲述上，个人认为是有些问题的。
来看下哪里有问题
- 首先看下 MySQL 的官方文档，我对比了 5.1、5.6、5.7 三个版本的 文档[1] ，对 MVCC 这部分的描述，几乎是相同的。
根据文档很明显是在每条数据增加三个隐藏列：
- 6字节的 DB_TRX_ID 字段，表示最近一次插入或者更新该记录的事务ID。
- 7字节的 DB_ROLL_PTR 字段，指向该记录的 rollback segment 的 undo log 记录。
- 6字节的 DB_ROW_ID，当有新数据插入的时候会自动递增。当表上没有用户主键的时候，InnoDB会自动产生聚集索引，包含DB_ROW_ID字段。
这里我补充一张包含 rollback segment 的 MySQL 内部结构图
版本链
之前我们讲过 undo_log 的概念，每条 undo日志都有一个 roll_pointer 属性，那么所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。
ReadView
通过隐藏列和版本链，MySQL 可以将数据恢复到指定版本；但是具体要恢复到哪个版本，则需要根据 ReadView 来确定。所谓 ReadView，是指事务（记做事务A）在某一时刻给整个事务系统（trx_sys）打快照，之后再进行读操作时，会将读取到的数据中的事务 id 与 trx_sys 快照比较，从而判断数据对该 ReadView 是否可见，即对事务A是否可见。（参考[2]）
至此我们发现 MVCC 就是基于隐藏字段、undo_log 链和 ReadView 来实现的。
Read committed 中的 MVCC
前面我们讲过 Read committed 隔离级别中使用 MVCC 解决脏读问题。
InnoDB只会查找版本早于当前事务版本的数据行（也就是，行的版本号小于或是等于事务的系统版本 号），这样可以确保数据读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或修改过的。因此不会产生脏读。
Read committed 隔离级别下出现不可重复读是由于 read view 的生成机制造成的。在 Read committed 级别下，只要当前语句执行前已经提交的数据都是可见的。在每次语句执行的过程中，都关闭 read view, 重新创建当前的一份 read view。这样就可以根据当前的全局事务链表创建 read view 的事务区间。简单说就是在 Read committed 隔离级别下，MVCC 在每次 select 时生成一个快照版本，所以每次 select 都会读到不同的版本数据，所以会产生不可重复读。
Repeatable read 中的 MVCC
Repeatable read 隔离级别解决了不可重复读的问题，一个事务中多次读取不会出现不同的结果，保证了可重复读。前文中我们说 Repeatable read 有两种实现方式，一种是悲观锁的方式，相对的 MVCC 就是乐观锁的方式。
Repeatable read 隔离级别能解决不可重复读根本原因其实就是 read view 的生成机制和 Read committed 不同。
- Read committed ：只要是当前语句执行前已经提交的数据都是可见的。
- Repeatable read ：只要是当前事务执行前已经提交的数据都是可见的。
不像 Read committed，在 Repeatable read 的隔离级别下，创建事务的时候，就生成了当前的 global read view,一直维持到事务结束。这样就能实现可重复读。
幻读与 Next-Key 锁
当前读与快照读
通过 MVCC 机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read) 参考[3]
- 快照读：就是select
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
总结
就写到这了，也算是给这段时间的面试做一个总结，查漏补缺，祝自己好运吧，也希望正在求职或者打算跳槽的 程序员看到这个文章能有一点点帮助或收获，我就心满意足了。多思考，多问为什么。希望小伙伴们早点收到满意的offer! 越努力越幸运！
金九银十已经过了，就目前国内的面试模式来讲，在面试前积极的准备面试，复习整个 Java 知识体系将变得非常重要，可以很负责任的说一句，复习准备的是否充分，将直接影响你入职的成功率。但很多小伙伴却苦于没有合适的资料来回顾整个 Java 知识体系，或者有的小伙伴可能都不知道该从哪里开始复习。我偶然得到一份整理的资料，不论是从整个 Java 知识体系，还是从面试的角度来看，都是一份含技术量很高的资料。
或者有的小伙伴可能都不知道该从哪里开始复习。我偶然得到一份整理的资料，不论是从整个 Java 知识体系，还是从面试的角度来看，都是一份含技术量很高的资料。**
[外链图片转存中…(img-hZtQq6V8-1711174587715)]
本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录
- 快照读：就是select