重新学习Mysql数据库8MySQL的事务隔离级别实战

35次阅读

共计 3058 个字符,预计需要花费 8 分钟才能阅读完成。

在 Mysql 中,事务主要有四种隔离级别,今天我们主要是通过示例来比较下,四种隔离级别实际在应用中,会出现什么样的对应现象。

  1. Read uncommitted (未提交读)
  2. Read committed (已提交读)
  3. Repeatable read (可重复读)
  4. Serializable (可串行化)

在理解四种隔离级别之前,我们需要先了解另外三个名词:

  1. 脏读
  2. 不可重复读
  3. 幻读

脏读

A 事务,会读取到 B 事务还未提交的数据。因为 B 事务可能会因为各种原因数据回滚,所以如果 A 事务读取了 B 未提交的数据,然后基于此进行一些业务操作,但是 B 事务发生错误回滚了,那 A 事务的业务操作就错了。

不可重复读

在同一个事务生命周期内,也就是这个事务还未提交之前。如果另外一个事务,对数据进行了编辑 (update) 或者删除 (delete) 操作。那么 A 事务就会读取到。简单理解,就是在一个事务生命周期内,多次查询数据,每次都可能查出来的不一样。

幻读

幻读的结果其实和不可重复读是一样的表现,差异就在于,不可重复读,主要是针对其他事务进行了编辑 (update) 和删除 (delete) 操作。而幻读主要是针对插入 (insert) 操作。也就是在一个事务生命周期内,会查询到另外一个事务新插入的数据。

下面我们就直接来通过实验来看,Mysql Innodb 中,不同的事务隔离级别,会出现怎么样的结果。

首先我们开启两个终端,查询当前 MySQL 的默认隔离级别:

<pre>SELECT @@global.tx_isolation; // 查询全局事务 SELECT @@session.tx_isolation; // 查询当前会话事务
</pre>

可以看到,默认的隔离级别是:REPEATABLE-READ

1. 实验 Read uncommitted

我们将会话事务设置为:Read uncommitted

<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
// 测试可以不用设置全局事务 SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;(这个可以不用设,只设置上面一行就可以了进行测试了)
</pre>

更改完之后,重新查询事务:

可以看到,全局事务已经更改为Read uncommitted

然后,我们首先创建一个测试的数据库test_tx,并插入了 2 条测试数据,如下图:

然后我们分别开启事务,然后我们在 B 终端中,插入一条数据,但是不提交,然后在 A 终端进行数据查询。

可以看到,我们在 B 终端 insert 一条数据,但是未进行提交操作 (commit),但是在 A 事务中,却查询到了。我们称这种现象叫做 脏读,在实际开发过程中,我们一般较少使用 Read uncommitted 隔离级别,这种隔离级别对任何的数据操作都不会进行加锁。

2. 实验 Read committed

首先我们将会话的事务隔离级别设置为read committed

<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
</pre>

然后我们用上面相同的方式,进行测试。首先同时将 2 个终端的事务开启:begin;,然后在 B 终端中插入一条新的数据insert into test_tx values(4,"Lee");,但是不提交事务(commit),然后在 A 终端中,查询数据,如图,我们在 A 终端中,没有查询到刚才插入的这条数据。

所以,实验表明,在 Read committed 隔离级别,不会出现 脏读 的问题。

然后我们继续做实验,看看在 Read committed 隔离级别中,会不会出现 不可重复读 幻读 的现象。

我们同时打开两个终端的事务,然后在 A 终端中,查询当前的数据,然后我们在 B 终端中,将 ID 为 3 的数据,name 修改为 Jeff。然后将 B 终端的事务提交(commit),但是 A 终端不提交事务,在一个事务的生命周期内,然后查询数据,我们查询到了刚才 B 终端修改过的数据。也就是说,我们在 A 终端的一个事务周期内(事务未 commit),两次查询,得到的结果是不一样的。

实验表明,在 Read committed 隔离级别中,存在 不可重复读 的现象。

我们继续做实验,因为刚才 B 终端已经将事务提交,所以我们重新打开 B 终端的事务,然后我们在 B 终端中,插入 (insert) 一条 ID 为 5 的新数据,并提交事务。然后我们回到 A 终端,查询数据,我们同样可以查询到刚才 B 终端新插入的数据。也就是说我们在 A 终端中,三次查询,得到的结果都是不一样的。

实验表明,在 Read committed 隔离级别中,存在 幻读 的现象。

总结,在 Read committed 隔离级别中,可以有效解决 脏读 问题,但是有 不可重复读 幻读 问题,而不可重复读和幻读的差异主要是,不可重复读主要是针对修改和删除操作、幻读针对插入数据操作。

3. 实验 Repeatable read

首先我们将隔离级别更改为Repeatable read

<pre>SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
</pre>

然后我们首先实验,在 Repeatable read 级别中是否存在 脏读 问题,我们首先同时开启 A,B 两个终端的事务 (begin;),然后在 B 终端中,插入一条 ID 为 6 的数据,但是不提交事务。然后在 A 终端中进行数据查询,结果是我们未查询到刚才插入的数据,所以在Repeatable read 级别中,没有 脏读 现象。

接着,我们顺着刚才的新插入的数据,然后将 B 终端的事务进行提交,然后再回到 A 终端查询数据,依然没有查询到 B 终端刚才插入的 ID 为 6 的数据,以此也就表明,目前 Mysql 5.6 以上的版本中,Repeatable read级别已经不存在 幻读 的问题,而之前的版本我并未做测试,后面有时间会在去查一下,mysql 是在哪个版本开始解决了幻读问题。

由于刚才 B 终端已经提交了事务,所以为了实验是否存在 不可重复读 的现象,我们重新开启 B 终端的事务,然后我们将 ID 为 5 的 name 修改为 Joy:update test_tx set name = "Joy" where id = 5;,同时 B 终端的事务 commit;,然后我们回到 A 终端进行查询,三次的查询结果都是一致的。所以实验表明,在Repeatable read 级别中,不存在 不可重复读 现象。

总结,在 Repeatable read 级别中,脏读 不可重复读 幻读 现象都没有。在 mysql 中,该级别也是默认的事务隔离级别,我们日常在开发中,也是主要使用该隔离级别。

4.Serializable

Serializable完全串行化的读,每次读都需要获得表级共享锁,读写相互会相互互斥,这样可以更好的解决数据一致性的问题,但是同样会大大的降低数据库的实际吞吐性能。所以该隔离级别因为损耗太大,一般很少在开发中使用。

©声明:除非注明,本站所有文章皆为原创,转载请以链接形式标明本文地址。
©转载请注明来源:https://www.rjkf.cn/spring-boot-shi-wu-ge-chi-ji-bie/

微信公众号【黄小斜】大厂程序员,互联网行业新知,终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」等关键字可以获取对应的免费学习资料。

                     

正文完
 0

重新学习Mysql数据库8MySQL的事务隔离级别实战

35次阅读

共计 3058 个字符,预计需要花费 8 分钟才能阅读完成。

在 Mysql 中,事务主要有四种隔离级别,今天我们主要是通过示例来比较下,四种隔离级别实际在应用中,会出现什么样的对应现象。

  1. Read uncommitted (未提交读)
  2. Read committed (已提交读)
  3. Repeatable read (可重复读)
  4. Serializable (可串行化)

在理解四种隔离级别之前,我们需要先了解另外三个名词:

  1. 脏读
  2. 不可重复读
  3. 幻读

脏读

A 事务,会读取到 B 事务还未提交的数据。因为 B 事务可能会因为各种原因数据回滚,所以如果 A 事务读取了 B 未提交的数据,然后基于此进行一些业务操作,但是 B 事务发生错误回滚了,那 A 事务的业务操作就错了。

不可重复读

在同一个事务生命周期内,也就是这个事务还未提交之前。如果另外一个事务,对数据进行了编辑 (update) 或者删除 (delete) 操作。那么 A 事务就会读取到。简单理解,就是在一个事务生命周期内,多次查询数据,每次都可能查出来的不一样。

幻读

幻读的结果其实和不可重复读是一样的表现,差异就在于,不可重复读,主要是针对其他事务进行了编辑 (update) 和删除 (delete) 操作。而幻读主要是针对插入 (insert) 操作。也就是在一个事务生命周期内,会查询到另外一个事务新插入的数据。

下面我们就直接来通过实验来看,Mysql Innodb 中,不同的事务隔离级别,会出现怎么样的结果。

首先我们开启两个终端,查询当前 MySQL 的默认隔离级别:

<pre>SELECT @@global.tx_isolation; // 查询全局事务 SELECT @@session.tx_isolation; // 查询当前会话事务
</pre>

可以看到,默认的隔离级别是:REPEATABLE-READ

1. 实验 Read uncommitted

我们将会话事务设置为:Read uncommitted

<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
// 测试可以不用设置全局事务 SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;(这个可以不用设,只设置上面一行就可以了进行测试了)
</pre>

更改完之后,重新查询事务:

可以看到,全局事务已经更改为Read uncommitted

然后,我们首先创建一个测试的数据库test_tx,并插入了 2 条测试数据,如下图:

然后我们分别开启事务,然后我们在 B 终端中,插入一条数据,但是不提交,然后在 A 终端进行数据查询。

可以看到,我们在 B 终端 insert 一条数据,但是未进行提交操作 (commit),但是在 A 事务中,却查询到了。我们称这种现象叫做 脏读,在实际开发过程中,我们一般较少使用 Read uncommitted 隔离级别,这种隔离级别对任何的数据操作都不会进行加锁。

2. 实验 Read committed

首先我们将会话的事务隔离级别设置为read committed

<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
</pre>

然后我们用上面相同的方式,进行测试。首先同时将 2 个终端的事务开启:begin;,然后在 B 终端中插入一条新的数据insert into test_tx values(4,"Lee");,但是不提交事务(commit),然后在 A 终端中,查询数据,如图,我们在 A 终端中,没有查询到刚才插入的这条数据。

所以,实验表明,在 Read committed 隔离级别,不会出现 脏读 的问题。

然后我们继续做实验,看看在 Read committed 隔离级别中,会不会出现 不可重复读 幻读 的现象。

我们同时打开两个终端的事务,然后在 A 终端中,查询当前的数据,然后我们在 B 终端中,将 ID 为 3 的数据,name 修改为 Jeff。然后将 B 终端的事务提交(commit),但是 A 终端不提交事务,在一个事务的生命周期内,然后查询数据,我们查询到了刚才 B 终端修改过的数据。也就是说,我们在 A 终端的一个事务周期内(事务未 commit),两次查询,得到的结果是不一样的。

实验表明,在 Read committed 隔离级别中,存在 不可重复读 的现象。

我们继续做实验,因为刚才 B 终端已经将事务提交,所以我们重新打开 B 终端的事务,然后我们在 B 终端中,插入 (insert) 一条 ID 为 5 的新数据,并提交事务。然后我们回到 A 终端,查询数据,我们同样可以查询到刚才 B 终端新插入的数据。也就是说我们在 A 终端中,三次查询,得到的结果都是不一样的。

实验表明,在 Read committed 隔离级别中,存在 幻读 的现象。

总结,在 Read committed 隔离级别中,可以有效解决 脏读 问题,但是有 不可重复读 幻读 问题,而不可重复读和幻读的差异主要是,不可重复读主要是针对修改和删除操作、幻读针对插入数据操作。

3. 实验 Repeatable read

首先我们将隔离级别更改为Repeatable read

<pre>SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
</pre>

然后我们首先实验,在 Repeatable read 级别中是否存在 脏读 问题,我们首先同时开启 A,B 两个终端的事务 (begin;),然后在 B 终端中,插入一条 ID 为 6 的数据,但是不提交事务。然后在 A 终端中进行数据查询,结果是我们未查询到刚才插入的数据,所以在Repeatable read 级别中,没有 脏读 现象。

接着,我们顺着刚才的新插入的数据,然后将 B 终端的事务进行提交,然后再回到 A 终端查询数据,依然没有查询到 B 终端刚才插入的 ID 为 6 的数据,以此也就表明,目前 Mysql 5.6 以上的版本中,Repeatable read级别已经不存在 幻读 的问题,而之前的版本我并未做测试,后面有时间会在去查一下,mysql 是在哪个版本开始解决了幻读问题。

由于刚才 B 终端已经提交了事务,所以为了实验是否存在 不可重复读 的现象,我们重新开启 B 终端的事务,然后我们将 ID 为 5 的 name 修改为 Joy:update test_tx set name = "Joy" where id = 5;,同时 B 终端的事务 commit;,然后我们回到 A 终端进行查询,三次的查询结果都是一致的。所以实验表明,在Repeatable read 级别中,不存在 不可重复读 现象。

总结,在 Repeatable read 级别中,脏读 不可重复读 幻读 现象都没有。在 mysql 中,该级别也是默认的事务隔离级别,我们日常在开发中,也是主要使用该隔离级别。

4.Serializable

Serializable完全串行化的读,每次读都需要获得表级共享锁,读写相互会相互互斥,这样可以更好的解决数据一致性的问题,但是同样会大大的降低数据库的实际吞吐性能。所以该隔离级别因为损耗太大,一般很少在开发中使用。

©声明:除非注明,本站所有文章皆为原创,转载请以链接形式标明本文地址。
©转载请注明来源:https://www.rjkf.cn/spring-boot-shi-wu-ge-chi-ji-bie/

微信公众号【黄小斜】大厂程序员,互联网行业新知,终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」等关键字可以获取对应的免费学习资料。

                     

正文完
 0