关于java:MVCC-水略深但是弄懂了真的好爽

@[toc]
后面写了一篇文章和大家分享了 MySQL 中查问表记录数的问题，里边波及到一个知识点 MVCC 多版本并发管制。这个问题不搞懂，总感觉毛病什么。因而明天我想花点工夫和大家聊一聊 MVCC。

要搞懂 MVCC，最好是要先懂 InnoDB 中事务的隔离级别，不然单纯看概念很难弄明确 MVCC。

MySQL 中事务的隔离级别一共分为四种，别离如下：

序列化（SERIALIZABLE）
可反复读（REPEATABLE READ）
提交读（READ COMMITTED）
未提交读（READ UNCOMMITTED）

四种不同的隔离级别含意别离如下：

SERIALIZABLE

如果隔离级别为序列化，则用户之间通过一个接一个程序地执行以后的事务，这种隔离级别提供了事务之间最大限度的隔离。

REPEATABLE READ

在可反复读在这一隔离级别上，事务不会被看成是一个序列。不过，以后正在执行事务的变动依然不能被内部看到，也就是说，如果用户在另外一个事务中执行同条 SELECT 语句数次，后果总是雷同的。（因为正在执行的事务所产生的数据变动不能被内部看到）。

READ COMMITTED

READ COMMITTED 隔离级别的安全性比 REPEATABLE READ 隔离级别的安全性要差。处于 READ COMMITTED 级别的事务能够看到其余事务对数据的批改。也就是说，在事务处理期间，如果其余事务批改了相应的表，那么同一个事务的多个 SELECT 语句可能返回不同的后果。

READ UNCOMMITTED

READ UNCOMMITTED 提供了事务之间最小限度的隔离。除了容易产生空幻的读操作和不能反复的读操作外，处于这个隔离级的事务能够读到其余事务还没有提交的数据，如果这个事务应用其余事务不提交的变动作为计算的根底，而后那些未提交的变动被它们的父事务撤销，这就导致了大量的数据变动。

在 MySQL 数据库种，默认的事务隔离级别是 REPEATABLE READ

接下来通过几条简略的 SQL 向读者验证下面的实践。

通过如下 SQL 能够查看数据库实例默认的全局隔离级别和以后 session 的隔离级别：

MySQL8 之前应用如下命令查看 MySQL 隔离级别：

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

查问后果如图：

能够看到，默认的隔离级别为 REPEATABLE-READ，全局隔离级别和以后会话隔离级别皆是如此。

MySQL8 开始，通过如下命令查看 MySQL 默认隔离级别：

SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;

就是关键字变了，其余都一样。

通过如下命令能够批改隔离级别（倡议开发者在批改时批改以后 session 隔离级别即可，不必批改全局的隔离级别）：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

下面这条 SQL 示意将以后 session 的数据库隔离级别设置为 READ UNCOMMITTED，设置胜利后，再次查问隔离级别，发现以后 session 的隔离级别曾经变了，如图 1 -2：

留神，如果只是批改了以后 session 的隔离级别，则换一个 session 之后，隔离级别又会复原到默认的隔离级别，所以咱们测试时，批改以后 session 的隔离级别即可。

1.2.2.1 筹备测试数据

READ UNCOMMITTED 是最低隔离级别，这种隔离级别中存在 脏读、不可反复读以及幻象读 问题，所以这里咱们先来看这个隔离级别，借此大家能够搞懂这三个问题到底是怎么回事。

上面别离予以介绍。

首先创立一个简略的表，预设两条数据，如下：

表的数据很简略，有 javaboy 和 itboyhub 两个用户，两个人的账户各有 1000 人民币。当初模仿这两个用户之间的一个转账操作。

留神，如果读者应用的是 Navicat 的话，不同的查问窗口就对应了不同的 session，如果读者应用了 SQLyog 的话，不同查问窗口对应同一个 session，因而如果应用 SQLyog，须要读者再开启一个新的连贯，在新的连贯中进行查问操作。

1.2.2.2 脏读

一个事务读到另外一个事务还没有提交的数据，称之为脏读。具体操作如下：

首先关上两个 SQL 操作窗口，假如别离为 A 和 B，在 A 窗口中输出如下几条 SQL（输出实现后不必执行）：

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
UPDATE account set balance=balance-100 where name='itboyhub';
COMMIT;

在 B 窗口执行如下 SQL，批改默认的事务隔离级别为 READ UNCOMMITTED，如下：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

接下来在 B 窗口中输出如下 SQL，输出实现后，首先执行第一行开启事务（留神只须要执行一行即可）：

START TRANSACTION;
SELECT * from account;
COMMIT;

接下来执行 A 窗口中的前两条 SQL，即开启事务，给 javaboy 这个账户增加 100 元。
进入到 B 窗口，执行 B 窗口的第二条查问 SQL（SELECT * from user;），后果如下：

能够看到，A 窗口中的事务，尽管还未提交，然而 B 窗口中曾经能够查问到数据的相干变动了。

这就是脏读问题。

1.2.2.3 不可反复读

不可反复读是指一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可反复读。具体操作步骤如下（操作之前先将两个账户的钱都复原为 1000）：

首先关上两个查问窗口 A 和 B，并且将 B 的数据库事务隔离级别设置为 READ UNCOMMITTED。具体 SQL 参考上文，这里不赘述。
在 B 窗口中输出如下 SQL，而后只执行前两条 SQL 开启事务并查问 javaboy 的账户：

START TRANSACTION;
SELECT * from account where name='javaboy';
COMMIT;

前两条 SQL 执行后果如下：

在 A 窗口中执行如下 SQL，给 javaboy 这个账户增加 100 块钱，如下：

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
COMMIT;

4. 再次回到 B 窗口，执行 B 窗口的第二条 SQL 查看 javaboy 的账户，后果如下：

javaboy 的账户曾经产生了变动，即前后两次查看 javaboy 账户，后果不统一，这就是 不可反复读。

和脏读的区别在于，脏读是看到了其余事务未提交的数据，而不可反复读是看到了其余事务曾经提交的数据（因为以后 SQL 也是在事务中，因而有可能并不想看到其余事务曾经提交的数据）。

1.2.2.4 幻象读

幻象读和不可反复读十分像，看名字就是产生幻觉了。

我举一个简略例子。

在 A 窗口中输出如下 SQL：

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

而后在 B 窗口输出如下 SQL：

START TRANSACTION;
SELECT * from account;
delete from account where name='zhangsan';
COMMIT;

咱们执行步骤如下：

首先执行 B 窗口的前两行，开启一个事务，同时查询数据库中的数据，此时查问到的数据只有 javaboy 和 itboyhub。
执行 A 窗口的前两行，向数据库中增加一个名为 zhangsan 的用户，留神不必提交事务。
执行 B 窗口的第二行，因为脏读问题，此时能够查问到 zhangsan 这个用户。
执行 B 窗口的第三行，去删除 name 为 zhangsan 的记录，这个时候删除就会出问题，尽管在 B 窗口中能够查问到 zhangsan，然而这条记录还没有提交，是因为脏读的起因才看到了，所以是没法删除的。此时就产生了幻觉，明明有个 zhangsan，却无奈删除。

这就是幻读。

看了下面的案例，大家应该明确了脏读、 不可反复读 以及幻读各自是什么含意了。

和 READ UNCOMMITTED 相比，READ COMMITTED 次要解决了脏读的问题，对于不可反复读和幻象读则未解决。

将事务的隔离级别改为 READ COMMITTED 之后，反复下面对于脏读案例的测试，发现曾经不存在脏读问题了；反复下面对于不可反复读案例的测试，发现不可反复读问题仍然存在。

下面那个案例不适用于幻读的测试，咱们换一个幻读的测试案例。

还是两个窗口 A 和 B，将 B 窗口的隔离级别改为 READ COMMITTED，

而后在 A 窗口输出如下测试 SQL：

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

在 B 窗口输出如下测试 SQL：

START TRANSACTION;
SELECT * from account;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

测试形式如下：

首先执行 B 窗口的前两行 SQL，开启事务并查问数据，此时查到的只有 javaboy 和 itboyhub 两个用户。
执行 A 窗口的前两行 SQL，插入一条记录，然而并不提交事务。
执行 B 窗口的第二行 SQL，因为当初曾经没有了脏读问题，所以此时查不到 A 窗口中增加的数据。
执行 B 窗口的第三行 SQL，因为 name 字段惟一，因而这里会无奈插入。此时就产生幻觉了，明明没有 zhangsan 这个用户，却无奈插入 zhangsan。

和 READ COMMITTED 相比，REPEATABLE READ 进一步解决了不可反复读的问题，然而幻象读则未解决。

REPEATABLE READ 中对于幻读的测试和上一大节基本一致，不同的是第二步中执行完插入 SQL 后记得提交事务。

因为 REPEATABLE READ 曾经解决了不可反复读，因而第二步即便提交了事务，第三步也查不到曾经提交的数据，第四步持续插入就会出错。

留神，REPEATABLE READ 也是 InnoDB 引擎的默认数据库事务隔离级别

SERIALIZABLE 提供了事务之间最大限度的隔离，在这种隔离级别中，事务一个接一个程序的执行，不会产生脏读、不可反复读以及幻象读问题，最平安。

如果设置以后事务隔离级别为 SERIALIZABLE，那么此时开启其余事务时，就会阻塞，必须等以后事务提交了，其余事务能力开启胜利，因而后面的脏读、不可反复读以及幻象读问题这里都不会产生。

总的来说，隔离级别和脏读、不可反复读以及幻象读的对应关系如下：

隔离级别	脏读	不可反复读	幻象读
READ UNCOMMITTED	容许	容许	容许
READ COMMITED	不容许	容许	容许
REPEATABLE READ	不容许	不容许	容许
SERIALIZABLE	不容许	不容许	不容许

性能关系如图：

松哥前不久也录过一个隔离级别的视频，大家能够参考下：

https://www.bilibili.com/video/BV14L4y1B7mB

接下来咱们还须要搞明确一个问题：快照读与以后读。

快照读（SnapShot Read）是一种一致性不加锁的读，是 InnoDB 存储引擎并发如此之高的外围起因之一。

在可反复读的隔离级别下，事务启动的时候，就会针对以后库拍一个照片（快照），快照读读取到的数据要么就是拍照时的数据，要么就是以后事务本身插入 / 批改过的数据。

咱们日常所用的不加锁的查问，包含本文第一大节中波及到的所有查问，都属于快照读，这个我就不演示了。

与快照读绝对应的就是以后读，以后读就是读取最新数据，而不是历史版本的数据，换言之，在可反复读隔离级别下，如果应用了以后读，也能够读到别的事务已提交的数据。

松哥举个例子：

MySQL 事务开启两个会话 A 和 B。

首先在 A 会话中开启事务并查问 id 为 1 的记录：

接下来咱们在 B 会话中对 id 为 1 的数据进行批改，如下：

留神 B 会话不要开启事务或者开启了及时提交事务，否则 update 语句占用一把排他锁会导致一会在 A 会话中用锁时产生阻塞。

接下来，回到 A 会话中持续做查问操作，如下：

能够看到，A 会话中第一个查问是快照读，读取到的是以后事务开启时的数据状态，前面两个查问则是以后读，读取到了以后最新的数据（B 会话中批改后的数据）。

咱们再来略微理解一下 undo log，这也有助于咱们了解前面的 MVCC，这里咱们简略介绍一下。

咱们晓得数据库事务有回滚的能力，既然可能回滚，那么就必须要在数据扭转之前先把旧的数据记录下来，作为将来回滚的根据，那么这个记录就是 undo log。

当咱们要增加一条记录的时候，就把增加的数据 id 记录到 undo log 中，将来回滚的时候就据此把数据删除；当咱们要删除或者批改数据的时候，就把原数据记录到 undo log 中，未来据此复原数据。查问操作因为不波及回滚操作，所以就不须要记录到 undo log 中。

接下来咱们再来看一看行格局，这也有助于咱们了解 MVCC。

行格局就是 InnoDB 在保留每一行的数据的时候，到底是以什么样的格局来保留这行数据的。

数据库中的行格局有好几种，例如 COMPACT、REDUNDANT、DYNAMIC、COMPRESSED 等，不过无论是哪种行格局，都绕不开上面几个暗藏的数据列：

上图中的列 1、列 2、列 3 始终到列 N，就是咱们数据库中表的列，保留着咱们失常的数据，除了这些保留数据的列之外，还有三列额定加进来的数据，这也是咱们这里要重点关注的 DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR 三列：

DB_ROW_ID：该列占用 6 个字节，是一个行 ID，用来惟一标识一行数据。如果用户在创立表的时候没有设置主键，那么零碎会依据该列建设主键索引。
DB_TRX_ID：该列占用 6 个字节，是一个事务 ID。在 InnoDB 存储引擎中，当咱们要开启一个事务的时候，会向 InnoDB 的事务零碎申请一个事务 id，这个事务 id 是一个 严格递增且惟一的数字，以后数据行是被哪个事务批改的，就会把对应的事务 id 记录在以后行中。
DB_ROLL_PTR：该列占用 7 个字节，是一个回滚指针，这个回滚指针指向一条 undo log 日志的地址，通过这个 undo log 日志能够让这条记录复原到前一个版本。

好啦，这是对于数据行格局的一些内容。

有了后面大节的准备常识，接下来咱们就来正式看一看 MVCC。

MVCC，英文全称是 Multi-Version Concurrency Control，中文译作多版本并发管制。

MVCC 的外围思路就是保留数据行的历史版本，通过对数据行的多个版本进行治理来实现数据库的并发管制。

简略来说，咱们平时看到的一条一条的记录，在数据库中保留的时候，可能不仅仅只有一条记录，而是有多个历史版本。

如下图：

这张图了解到位了，我想大家的 MVCC 也就了解的查不多了。

接下来我联合不同的隔离级别来和大家说这张图。

首先，当咱们通过 INSERT\DELETE\UPDATE 去操作一行数据的时候，就会产生一个事务 id，这个事务 id 也会同时保留在行记录中（DB_TRX_ID），也就是说，以后数据行是哪个事务批改后失去的，是有记录的。

INSERT\DELETE\UPDATE 操作都会产生对应的 undo log 日志，每一行记录都有一个 DB_ROLL_PTR 指向 undo log 日志，每一行记录，通过执行 undo log 日志，就能够复原到前一个记录、前前记录、前前前记录 …

当咱们开启一个事务的时候，首先会向 InnoDB 的事务零碎申请一个事务 id，这个 id 是一个严格递增的数字，在以后事务开启的一瞬间零碎会创立一个数组，数组中保留了目前所有的沉闷事务 id，所谓的沉闷事务就是指已开启然而还没有提交的事务。

这个数组中的最小值好了解，有的小伙伴可能会误以为数组中的最大值就是的以后事务的 id，其实这个不肯定，也有可能更大。因为从申请到 trx_id 到创立数组之间也是须要工夫的，这期间可能有其余会话也申请到了 trx_id。

当以后事务想要去查看某一行数据的时候，会先去查看该行数据的 DB_TRX_ID：

如果这个值等于以后事务 id，阐明这就是以后事务批改的，那么数据可见。
如果这个值小于数组中的最小值，阐明当咱们开启以后事务的时候，这行数据批改所波及到的事务曾经提交了，以后数据行是可见的。
如果这个值大于数组中的最大值，阐明这行数据是咱们在开启事务之后，还没有提交的时候，有另外一个会话也开启了事务，并且批改了这行数据，那么此时这行数据就是不可见的。
如果这个值的大小介于数组中最大值最小值之间（闭区间），且该值不在数组中，阐明这也是一个曾经提交的事务批改的数据，这是可见的。
如果这个值的大小介于数组中最大值最小值之间（闭区间），且该值在数组中（不等于以后事务 id），阐明这是一个未提交的事务批改的数据，不可见。

前三种状况应该很好了解，次要是前面两种，松哥举一个简略例子。

比方咱们有 A、B、C、D 四个会话，首先 A、B、C 别离开启一个事务，事务 ID 是 3、4、5，而后 C 会话提交了事务，A、B 未提交。接下来 D 会话也开启了一个事务，事务 ID 是 6，那么当 D 会话开启事务的时候，数组中的值就是 [3,4,6]。当初假如有一行数据的 DB_TRX_ID 是 5（第四种状况），那么该行数据就是可见的（因为以后事务开启的时候它曾经提交了）；如果有一行数据的 DB_TRX_ID 是 4，那么该行就不可见（因为未提交）。

另外还有一个须要留神的中央，就是如果以后事务中波及到数据的更新操作，那么更新操作是在以后读的根底上更新的，而不是快照读的根底上更新的，如果是后者则有可能导致数据失落。

我举一个例子，假如有如下表：

当初有两个会话 A 和 B，首先在 A 中开启事务：

而后在会话 B 中做一次批改操作（不必显式开启事务，更新 SQL 外部会开启事务，更新实现后事务会主动提交）：

接下来回到会话 A 中，查问该条记录发现值没变，合乎预期（目前隔离级别是可反复读），而后在 A 中做一次批改操作，批改实现后再去查问，如下图：

能够看到，更新其实是在 100 的根底上更新的，这个也好了解，要是在 99 的根底上更新，那么就会失落掉 100 的那次更新，显然是不对的。

其实 MySQL 中的 update 就是先读再更新，读的时候默认就是以后读，即会加锁。所以在下面的案例中，如果 B 会话中显式的开启了事务并且没有没有提交，那么 A 会话中的 update 语句就会被阻塞。

这就是 MVCC，一行记录存在多个版本。实现了读写并发管制，读写互不阻塞；同时 MVCC 中采纳了乐观锁，读数据不加锁，写数据只锁行，升高了死锁的概率；并且还能据此实现快照读。

READ COMMITTED 和 REPEATABLE READ 相似，区别次要是后者在每次事务开始的时候创立一致性视图（创立数组列出沉闷事务 id），而前者则每一个语句执行前都会从新算出一个新的视图。

所以 READ COMMITTED 这种隔离级别会看到别的会话曾经提交的数据（即便别的会话比以后会话开启的晚）。

MVCC 在肯定水平上实现了读写并发，不过它只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下无效。

而 READ UNCOMMITTED 总是会读取最新的数据行，SERIALIZABLE 则会对所有读取的行都加锁，这两个都和 MVCC 不兼容。

好啦，不晓得小伙伴们看明确没有，有问题欢送留言探讨。

关于java:MVCC-水略深但是弄懂了真的好爽

1. 隔离级别

1.1 实践

1.2 SQL 实际

1.2.1 查看隔离级别

1.2.2 READ UNCOMMITTED

1.2.2.1 筹备测试数据

1.2.2.2 脏读

1.2.2.3 不可反复读

1.2.2.4 幻象读

1.2.3 READ COMMITTED

1.2.4 REPEATABLE READ

1.2.5 SERIALIZABLE

1.3 总结

2. 快照读与以后读

2.1 快照读

2.2 以后读

3. undo log

4. 行格局

5. MVCC

5.1 REPEATABLE READ

5.2 READ COMMITTED

6. 小结