MySQL四种隔离级别和MVCC

时间 2019-12-09

标签 mysql 四种隔离级别 mvcc 栏目 MySQL 繁體版

原文原文链接

事务在一个数据库中的地位尤其重要，尤为是高并发的场合。保证数据库操做的原子性和错误出现状况下的回滚，对数据的安全性和可靠性提供了保障。事务有四大原则，即ACID原则。网上关于这个问题的文章有不少，读者能够到网上看看相关的文章，我这里就不赘述了。可是须要注意的是，MySQL默认是不开启事务的，默认状况是autocommit自动提交，而若是想开启事务，须要数据库管理员或者开发者手动输入begin来开启事务。php

本文主要介绍四大原则中的I原则，即隔离级别。并在讲述I原则的时候，顺带讨论MVCC。由于MVCC一般和隔离级别是讨论到一块的。html

事务的隔离级别实际上是SQL语言的标准，这里我就以本身比较经常使用的MySQL数据库为例进行介绍。mysql

客户端输入命令：sql

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL数据库

{READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}安全

小提示：也可使用小写，MySQL是不分大小写的。服务器

在MySQL Workbench输入命令查询系统默认的隔离状态网络

MySQL默认状况下是repeatable read。session

设置当前会话隔离级别并发

设置当前会话（客户端）的隔离级别，当客户端关闭后从新进入，隔离级别会恢复到系统的全局隔离状态。

理解‘当前会话’：

MySQL中认为，打开一个客户端就是开启一个会话。其实质是创建一个网络链接。这个网络链接是有状态性的，一旦关闭，此会话级别中设置的变量就会恢复为系统的变量。

设置全局隔离级别

设置全局隔离级别的时候，只对全局进行修改，当前会话仍是会保持原来的设置，退出从新登陆才会遵循全局的设置。

在MySQL Workbench中输入命令：

或者在终端输入

mysql> show variables like '%isolation';
+-----------------------+----------------+
| Variable_name         | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
| tx_isolation          | READ-COMMITTED |
+---------------- ------+----------------+
2 rows in set, 1 warning (0.00 sec)

另一种方法：

在ini文件（Linux为conf文件）设置全局的隔离级别

[mysqld]

添加：

transaction-isolation = READ-COMMITTED

不过这种状况须要重启服务器，因此不太建议使用这种方式，除非是几乎没有请求的深夜时候进行。

C:\WINDOWS\system32> net stop mysql

MySQL 服务正在中止..

MySQL 服务已成功中止。

 

C:\WINDOWS\system32> net start mysql

MySQL 服务正在启动 .

MySQL 服务已经启动成功。

关于以上命令，有一些须要理解的点：

1）隔离级别优先级顺序 read uncommittd < read committed < repeatable read < serializable

个人理解是每个级别都是在上一级别的基础上增长了表操做的限制。读者往下看就能够体会到这种限制的增强。

2）session和global

1. 默认行为（不带session和global）是为下一个（未链接）会话设置隔离级别。

2. 若是使用GLOBAL关键字，此命令语句在全局中对从那点开始建立的全部新链接设置事务级别。

3. 使用SESSION 关键字为当前链接上执行的事务设置默认事务级别。

4. 任何客户端在任什么时候候都能自由改变会话/全局隔离级别（甚至在事务的中间），或者为下一个事务设置隔离级别。

实际测试中，因为是本地链接，一些状况没法模拟出来，并且手动也很难作一些模拟高并发的情形，能够借助一些测试工具来进行。例如sysbench，《高性能MySQL》中也有一章专门写了基准测试。

下面是对四个隔离级别的介绍

1. Read Uncommitted 读取未提交的事务

一个数据库链接实例中，它的未提交事务执行了对数据库的增删改操做，这些操做对数据的更改是没有提交到服务器磁盘的，可是在高并发的状况下，本链接的事务会不断更新数据库以获取其余链接的事务对数据库进行的最新的更改。那么第一个事务查询操做读取的数据多是不真实的，人家都尚未提交！因此这种状况下就会出现了所谓的脏读。通常，在现实中不多使用这个级别，除非是对数据的真实性要求不高，只想得到最新的数据的状况。想一想在一些金融领域的电子现金系统或者商城购物车系统使用这个级别会是怎样一个情形？

2. Read Committed 读取已经提交的事务

此级别在本会话中对数据库进行查询，会读取已经提交（commit）了SQL语句的事务结果，而未提交的事务的操做对数据库所形成的影响是不会读取的。能够这样理解，这个级别更像是‘事务级别’，即不一样事务间内部的操做互不影响，只有提交了事务才会对其余事务产生影响。

Read committed级别同时也是nonrepeatable read级别（是相对下面的Repeatable Read而言的），即不要求重复读。一个事务先后两次的读取内容能够是不一样的，即容许在本事务查询的过程当中其余事务对本事务查询的数据进行其余操做，这样就会出现先后两次读取的数据的不一致性。此处涉及到MVCC和乐观锁、悲观锁的概念，后面会讲述。咱们先讨论这种机制的运行逻辑。

想象一下下面这种情形：高并发状况下，多个数据库链接同时对数据库提交操做。本事务因为SQL语句比较多，执行起来比较慢。而在这期间（有时多是1s内），有另外两个链接同时在执行操做，一个链接对一行数据的某一列进行增长2操做，而另一个链接对同一行数据的这一列数据进行减3操做，它们在对数据库的实现上可能相差的时间很小，可能仅在毫秒之间这个时候就会出现两个vesion版本的结果，一个是执行了一个事务的版本，另外一个是执行了两个事务的版本。那么本事务究竟读取哪个版本呢？答案是指读取执行了两条事务的版本。由于在本事务内，会不断去‘查看’其余事务的提交状况，并将最新的提交状况‘反馈’在本事务中。

3. Repeatable Read 可重复读

Repeatable Read正好与上面的Read Committed相反，本事务会读取第一个version的数据。由于在进行第一次查询操做的时候，可能第一个事务已经提交了，而第二个事务还没提交。而不管后面第二个事务甚至更多个事务提交了，但本事务中再次读取的数据时只会读取是第一读取的相同数据，即‘无视’其余事务对此行数据的更改。能够理解，在这里是悲观锁发挥了做用，即锁住了本事务，其余事务的数据的更改就没法影响到本事务。而在Read Committed级别中，发挥做用的是乐观锁，其实就是什么也不锁定，只在更新数据的时候锁定（下面有更详细描述）。因此在本事务的先后两次范围查询中会出现数据不一致的幻读现象。

4. Serilizable 串行化

数据库最高级别的隔离限制，事务与事务之间串行化的。即一个事务在执行任何操做的时候，都不容许其余事务对本事务查询范围内的数据有任何操做，这里会引入一个共享锁的概念，即本事务的查询操道别读取的数据锁住了，必须等本事务完成以后才容许其余事务获取这个共享锁进行其余操做，就比如如排着队一个个执行。

MVCC

MVCC, Multiversion Concurrency Control多版本并发控制。MVCC是行级锁的一个变种，可是它在不少状况下避免了加锁操做, 所以服务器的开销更低（减小了锁的生产和分配）。虽然实现机制有所不一样, 但大都实现了非阻塞的读操做，写操做也只锁定必要的行。

在实现上，MySQL经过三个列实现对版本的控制，即6字节的事务ID(DB_TRX_ID)字段，7字节的回滚指针(DB_ROLL_PTR)字段，6字节的DB_ROW_ID字段。更多相关内容推荐看这篇文章，里面讲得很详细 https://juejin.im/entry/5a4b52eef265da431120954b

而实际上InnoDB并不是彻底意义上的MVCC，由于没有实现多版本并存。关键在于并存两字，即在事务执行对数据操做时同时存在多个版本。而不管如何MySQL在事务执行的时候是串行化的，即便这两个事务几乎同时发生。其实这正是对数据安全性的一个保障。

MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工做。其余两个隔离级别和MVCC不兼容。

悲观锁：

悲观锁的特色是先获取锁，再进行业务操做，即“悲观”的认为获取锁是很是有可能失败的，所以要先确保获取锁成功再进行业务操做。

乐观锁：

乐观锁的特色先进行业务操做，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，所以在进行完事务操做须要实际更新数据的最后一步再去拿一下锁就好。

在实战中怎么使用，仍是要看具体的数据量和业务逻辑来进行选择。

更新说明：随着本身对MySQL数据库隔离级别的更多理解，本文在以前的内容基础上进行从新整理，而且添加上了MVCC的内容。18.12.25

参考文章：

https://www.cnblogs.com/phpper/p/7345332.html

https://juejin.im/entry/5a4b52eef265da431120954b