【MySQL】事务管理

文章目录

  • 什么是事务
  • 为什么会出现事务
  • 事务的版本支持
  • 事务的提交方式
  • 事务的相关演示
  • 事务的隔离级别
    • 查看与设置隔离级别
    • 读未提交(Read Uncommitted)
    • 读提交(Read Committed)
    • 可重复读(Repeatable Read)
    • 串行化(Serializable)
  • 关于一致性
  • 多版本并发控制
    • 记录中的3个隐藏字段
    • undo日志
    • 快照
    • Read View
  • RR 与 RC 的本质区别


什么是事务

事务 就是一组DML语句组成,这些语句在逻辑上存在相关性,这一组DML语句要么全部成功,要么全部失败,是一个整体。MySQL提供一种机制,保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。事务就是要做的或所做的事情,主要用于处理操作量大,复杂度高的数据,比如转账就涉及多条SQL语句,包括查询余额(select)、在当前账户上减去指定金额(update)、在指定账户上加上对应金额(update)等,将这多条SQL语句打包便构成了一个事务。

MySQL同一时刻可能存在大量事务,如果不对这些事务加以控制,在执行时就可能会出现问题。比如单个事务内部的某些SQL语句执行失败,或是多个事务同时访问同一份数据导致数据不一致的问题。

因此一个完整的事务绝对不是简单的SQL集合,还需要满足如下四个 特性

  • 原子性: 一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中如果发生错误,则会自动回滚到事务开始前的状态,就像这个事务从来没有执行过一样。
  • 持久性: 事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
  • 隔离性: 数据库允许多个事务同时访问同一份数据,隔离性可以保证多个事务在并发执行时 ,不会因为由于交叉执行而导致数据的不一致。
  • 一致性: 在事务开始之前和事务结束之后,数据库的完整性没有被破坏,这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库的可以自发性地完成预设的工作。

上面的四个属性简称ACID

  • 原子性(Atomicity,又称不可分割性)。
  • 一致性(Consistency)。
  • 隔离性(Isolation,又称独立性)。
  • 持久性(Durability)。

其中原子性、隔离性和持久性是手段,一致性是目的。只要原子性、隔离性和持久性能够保证,那么一致性一定能够保证。


为什么会出现事务

十五被MySQL编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题。如果MySQL只是单纯的提供数据存储服务,那么用户在访问数据库时就需要自行考虑各种潜在问题,包括网络异常、服务器宕机等。因此事务本质是为了应用服务的,而不是伴随着数据库系统天生就有的。


事务的版本支持

MySQL中只有使用了 InnoDB 数据库引擎的数据库或表才支持事务,MyISAM 不支持。

在这里插入图片描述

  • Engine: 表示存储引擎的名称。
  • Support: 表示服务器对存储引擎的支持级别,YES表示支持,NO表示不支持,DEFAULT表示数据库默认使用的存储引擎,DISABLED表示支持引擎但已将其禁用。
  • Comment: 表示存储引擎的简要说明。
  • Transactions: 表示存储引擎是否支持事务,可以看到InnoDB存储引擎支持事务,而MyISAM存储引擎不支持事务。
  • XA: 表示存储引擎是否支持XA事务。
  • Savepoints: 表示存储引擎是否支持保存点。

事务的提交方式

💕 查看事务的提交方式

show variables like 'autocommit';

在这里插入图片描述

💕 设置事务的提交方式

set autocommit=0/1;

在这里插入图片描述


事务的相关演示

💕 查看隔离级别

mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ | -- 可重复读
+-----------------+
1 row in set, 1 warning (0.00 sec)

💕 设置读未提交的隔离级别

mysql> set global transaction isolation level READ UNCOMMITTED;
Query OK, 0 rows affected (0.00 sec)mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec)

当我们设置完隔离级别后需要重新登录才能生效。

在这里插入图片描述

准备测试表

创建一个银行用户表,表中包含用户的id、姓名和账户余额。如下:

在这里插入图片描述

💕 事务的开始与回滚

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

说明一下:

  • 使用beginstart transaction命令,可以启动一个事务。
  • 使用savepoint 保存点命令,可以在事务中创建指定名称的保存点。
  • 使用rollback to 保存点命令,可以让事务回滚到指定保存点。
  • 使用rollback命令,可以直接让事务回滚到最开始。
  • 使用commit命令,可以提交事务,提交事务后就不能回滚了。

💕 原子性

在这里插入图片描述
如果左终端中的事务在提交之前因为某些原因与MySQL断开连接,那么MySQL会自动让事务回滚到最开始,这时右终端中就看不到之前插入的记录了。

💕 持久性

在这里插入图片描述

左终端中的事务在提交后与MySQL断开连接,这时右终端中仍然可以看到之前插入的记录,因为事务提交后数据就被持久化了。

💕 begin会自动更改提交方式

在这里插入图片描述

如果左终端中的事务在提交之前与MySQL断开连接,那么MySQL依旧会自动让事务回滚到最开始,这时右终端中就看不到之前新插入的记录了。也就是说,使用begin或start transaction命令启动的事务,都必须要使用commit命令手动提交,数据才会被持久化,与是否设置autocommit无关。

实际全局变量autocommit是否被设置影响的是单条SQL语句,InnoDB中的每一条SQL都会默认被封装成事务。autocommit 为ON,则单条SQL语句执行后会自动被提交,如果为OFF,则SQL语句执行后需要使用 commit 进行手动提交。 实际我们之前一直都在使用单SQL事务,只不过autocommit默认是打开的,因此单SQL事务执行后自动就被提交了。


事务的隔离级别

  • MySQL服务可能会同时被多个客户端进程(线程)访问,访问的方式以事务的方式进行。
  • 一个事务可能由多条SQL语句构成,也就意味着任何一个事务,都有执行前、执行中和执行后三个阶段,而所谓的原子性就是让用户层要么看到执行前,要么看到执行后,执行中如果出现问题,可以随时进行回滚,所以单个事务对用户表现出来的特性就是原子性。
  • 但毕竟每个事务都有一个执行的过程,在多个事务各自执行自己的多条SQL时,仍然可能会出现互相影响的情况,比如多个事务同时访问同一张表,甚至是表中的同一条记录。
  • 数据库为了保证事务执行过程中尽量不受干扰,于是出现了隔离性的概念,而数据库为了允许事务在执行过程中受到不同程度的干扰,于是出现了隔离级别的概念。

数据库的隔离级别有以下四种:

  • 读未提交(Read Uncommitted): 在该隔离级别下,所有的事务都可以看到其他事务没有提交的执行结果,实际生产中不可能使用这种隔离级别,因为这种隔离级别相当于没有任何隔离性,会存在很多并发问题,如 脏读、幻读、不可重复读 等。
  • 读提交(Read Committed): 该隔离级别是大多数数据库的默认隔离级别,但它不是MySQL默认的隔离级别,它满足了隔离的简单定义:一个事务只能看到其他已经提交的事务所做的改变,但这种隔离级别存在 不可重复读幻读 的问题。
  • 可重复读(Repeatable Read): 这是MySQL默认的隔离级别,该隔离级别确保同一个事务在执行过程中,多次读取操作数据时会看到同样的数据,即解决了不可重复读的问题,但这种隔离级别下仍然存在 幻读 的问题。
  • 串行化(Serializable): 这是事务的最高隔离级别,该隔离级别通过强制事务排序,使之不可能相互冲突,从而解决了幻读问题。它在每个读的数据行上面加上共享锁,但是可能会导致超时和锁竞争问题,这种隔离级别太极端,实际生成中基本不使用。

虽然数据库事务的隔离级别有以上四种,但一个稳态的数据库只会选择这其中的一种,作为自己的默认隔离级别。但数据库默认的隔离级别有时可能并不满足上层的业务需求,因此数据库提供了这四种隔离级别,可以让我们自行设置。隔离级别基本上都是通过加锁的方式实现的,不同的隔离级别对锁的使用是不同的,常见的有表锁、行锁、写锁、间隙锁(GAP)、Next-Key锁(GAP+行锁)等。


查看与设置隔离级别

查看全局隔离级别

select @@global.tx_isolation;

在这里插入图片描述

查看会话隔离级别

select @@session.tx_isolation;

在这里插入图片描述

此外,通过 select @@tx_isolation 命令,也可以查看当前会话的隔离级别。如下:

在这里插入图片描述

设置会话隔离级别

通过 set session transaction isolation level 隔离级别命令,可以设置当前会话的隔离级别。

在这里插入图片描述

说明一下: 设置会话的隔离级别只会影响当前会话,新起的会话依旧采用全局隔离级。

设置全局隔离级别

通过 set global transaction isolation level 隔离级别 命令,可以设置全局隔离级别。

在这里插入图片描述

设置全局隔离级别会影响后续的新会话,但当前会话的隔离级别没有发生变化,如果要让当前会话的隔离级别也改变,则需要重启会话。


读未提交(Read Uncommitted)

启动两个终端,将隔离级别设置为读未提交,并查看此时银行用户表中的数据。如下:

在这里插入图片描述

在两个终端各自启动一个事务,左终端中的事务所作的修改在没有提交之前,右终端中的事务就已经能够看到了。

在这里插入图片描述

说明一下:

  • 读未提交是事务的最低隔离级别,几乎没有加锁,虽然效率高,但是问题比较多,所以严重不建议使用。
  • 一个事务在执行过程中,读取到另一个执行中的事务所做的修改,但是该事务还没有进行提交,这种现象叫做脏读。

读提交(Read Committed)

启动两个终端,将隔离级别都设置为读提交,并查看此时银行用户表中的数据。

在这里插入图片描述

左边的事务所做的修改在没有提交之前,右边终端是无法看到的。

在这里插入图片描述

当左终端中的事务提交后,右终端中的事务才能看到修改后的数据。

在这里插入图片描述

一个事务在执行过程中,两个相同的select查询得到了不同的数据,这种现象叫做 不可重复读


可重复读(Repeatable Read)

启动两个终端,将隔离级别都设置为可重复读,并查看此时银行用户表中的数据。如下:

在这里插入图片描述

两个终端各自启动一个事务,左终端中的事务所作的修改在没有提交之前,右终端中的事务无法看到。

在这里插入图片描述

并且当左终端中的事务提交后,右终端中的事务仍然看不到修改后的数据。

在这里插入图片描述

只有当右终端中的事务提交后再查看表中的数据,这时才能看到修改后的数据。

在这里插入图片描述

说明一下:

  • 在可重复读隔离级别下,一个事务在执行过程中,相同的select查询得到的是相同的数据,这就是所谓的可重复读。
  • 一般的数据库在可重复读隔离级别下,update数据是满足可重复读的,但insert数据会存在幻读问题,因为隔离性是通过对数据加锁完成的,而新插入的数据原本是不存在的,因此一般的加锁无法屏蔽这类问题。
  • 一个事务在执行过程中,相同的select查询得到了新的数据,如同出现了幻觉,这种现象叫做幻读。
  • MySQL是通过Next-Key锁(GAP+行锁)来解决幻读问题的。

串行化(Serializable)

启动两个终端,将隔离级别都设置为串行化,并查看此时银行用户表中的数据
在这里插入图片描述

在两个终端各自启动一个事务,如果这两个事务都对表进行的是读操作,那么这两个事务可以并发执行,不会被阻塞。

在这里插入图片描述

但如果这两个事务中有一个事务要对表进行写操作,那么这个事务就会立即被阻塞。

在这里插入图片描述

直到访问这张表的其他事务都提交后,这个被阻塞的事务才会被唤醒,然后才能对表进行修改操作。

在这里插入图片描述

串行化是事务的最高隔离级别,多个事务同时进行读操作时加的是共享锁,因此可以并发执行读操作,但一旦需要进行写操作,就会进行串行化,效率很低,几乎不会使用。


总结:

在这里插入图片描述

  • 隔离级别越严格,安全性越高,但数据库的并发性能也就越低,在选择隔离级别时往往需要在两者之间找一个平衡点。
  • 表中只写出了各种隔离级别下进行读操作时是否需要加锁,因为无论哪种隔离级别,只要需要进行写操作就一定需要加锁。

关于一致性

事务执行的结果,必须使数据库从一个一致性状态,变到另一个一致性状态,当数据库只包含事务成功提交的结果时,数据库就处于 一致性状态

  • 事务在执行过程中如果发生错误,则需要自动回滚到事务最开始的状态,就像这个事务从来没有执行过一样,即一致性需要原子性来保证。
  • 事务处理结束后,对数据的修改必须是永久的,即便系统故障也不能丢失,即一致性需要持久性来保证。
  • 多个事务同时访问同一份数据时,必须保证这多个事务在并发执行时,不会因为由于交叉执行而导致数据的不一致,即一致性需要隔离性来保证。
  • 此外,一致性与用户的业务逻辑强相关,如果用户本身的业务逻辑有问题,最终也会让数据库处于一种不一致的状态。

也就是说,一致性实际是数据库最终要达到的效果,一致性不仅需要原子性、持久性和隔离性来保证,还需要上层用户编写出正确的业务逻辑。


多版本并发控制

数据库并发的场景有三种:

  • 读-读 :不存在任何问题,也不需要并发控制
  • 读-写 :有线程安全问题,可能会造成事务隔离性问题,可能遇到脏读,幻读,不可重复读
  • 写-写 :有线程安全问题,可能会存在更新丢失问题,比如第一类更新丢失,第二类更新丢失

说明一下:

  • 写-写并发场景下的第一类更新丢失又叫做回滚丢失,即一个事务的回滚把另一个已经提交的事务更新的数据覆盖了,第二类更新丢失又叫做覆盖丢失,即一个事务的提交把另一个已经提交的事务更新的数据覆盖了。
  • 读-读并发不需要进行并发控制,写-写并发实际也就是对数据进行加锁,这里最值得讨论的是读-写并发,读-写并发是数据库当中最高频的场景,在解决读-写并发时不仅需要考虑线程安全问题,还需要考虑并发的性能问题。

多版本并发控制

多版本并发控制(Multi-Version Concurrency Control,MVCC) 是一种用来解决读写冲突的无锁并发控制,主要依赖记录中的 3个隐藏字段、undo日志和Read View 实现。

  • 为事务分配单向增长的事务ID,为每个修改保存一个版本,将版本与事务ID相关联,读操作只读该事务开始前的数据库快照。
  • MVCC保证读写并发时,读操作不会阻塞写操作,写操作也不会阻塞读操作,提高了数据库并发读写的性能,同时还可以解决脏读、幻读和不可重复读等事务隔离性问题。

记录中的3个隐藏字段

数据库中的每条记录都会有如下3个隐藏字段:

  • DB_TRX_ID:6字节,创建或最近一次修改该记录的事务ID。
  • DB_ROW_ID:6字节,隐含的自增ID(隐藏主键)。
  • DB_ROLL_PTR:7字节,回滚指针,指向这条记录的上一个版本。

说明一下:

  1. 采用InnoDB存储引擎建立的每张表都会有一个主键,如果用户没有设置,InnoDB就会自动以DB_ROW_ID产生一个聚簇索引。
  2. 此外,数据库表中的每条记录还有一个删除flag隐藏字段,用于表示该条记录是否被删除,便于进行数据回滚。

示例

创建一个学生表,表中包含学生的姓名和年龄。如下:

在这里插入图片描述

当向表中插入一条记录后,该记录不仅包含name和age字段,还包含三个隐藏字段。如下:

在这里插入图片描述

  • 假设插入该记录的事务的事务ID为9,那么该记录的DB_TRX_ID字段填的就是9。
  • 因为这是插入的第一条记录,所以隐式主键DB_ROW_ID字段填的就是1。
  • 由于这条记录是新插入的,没有历史版本,所以回滚指针DB_ROLL_PTR的值设置为null。
  • MVCC重点需要的就是这三个隐藏字段,实际还有其他隐藏字段,只不过没有画出。

undo日志

MySQL的三大日志如下:

  1. redo log:重做日志,用于MySQL崩溃后进行数据恢复,保证数据的持久性。
  2. bin log:逻辑日志,用于主从数据备份时进行数据同步,保证数据的一致性。
  3. undo log:回滚日志,用于对已经执行的操作进行回滚,保证事务的原子性。

MySQL会为上述三大日志开辟对应的缓冲区,用于存储日志相关的信息,必要时会将缓冲区中的数据刷新到磁盘。

MVCC的实现主要依赖三大日志中的undo log,记录的历史版本就是存储在undo log对应的缓冲区中的。


快照

现在有一个事务ID为10的事务,要将刚才插入学生表中的记录的学生姓名改为“李四”:

  • 因为是要进行写操作,所以需要先给该记录加行锁。
  • 修改前,先将该行记录拷贝到undo log中,此时undo log中就有了一行副本数据。
  • 然后再将原始记录中的学生姓名改为“李四”,并将该记录的DB_TRX_ID改为10,回滚指针DB_ROLL_PTR设置成undo log中副本数据的地址,从而指向该记录的上一个版本。
  • 最后当事务10提交后释放锁,这时最新的记录就是学生姓名为“李四”的那条记录。

在这里插入图片描述

现在又有一个事务ID为11的事务,要将刚才学生表中的那条记录的学生年龄改为38:

  • 因为是要进行写操作,所以需要先给该记录(最新的记录)加行锁。
  • 修改前,先将该行记录拷贝到undo log中,此时undo log中就又有了一行副本数据。
  • 然后再将原始记录中的学生年龄改为38,并将该记录的DB_TRX_ID改为11,回滚指针DB_ROLL_PTR设置成刚才拷贝到undo log中的副本数据的地址,从而指向该记录的上一个版本。
  • 最后当事务11提交后释放锁,这时最新的记录就是学生年龄为38的那条记录。

修改后的示意图如下:

在这里插入图片描述

此时我们就有了一个基于链表记录的历史版本链,而undo log中的一个个的历史版本就称为一个个的快照。

说明一下:

  1. 所谓的回滚实际就是用undo log中的历史数据覆盖当前数据,而所谓的创建保存点就可以理解成是给某些版本做了标记,让我们可以直接用这些版本数据来覆盖当前数据。
  2. 这种技术实际就是基于版本的写时拷贝,当需要进行写操作时先将最新版本拷贝一份到undo log中,然后再进行写操作,和父子进程为了保证独立性而进行的写时拷贝是类似的。

insertdelete的记录如何维护版本链?

  1. 删除记录并不是真的把数据删除了,而是先将该记录拷贝一份放入undo log中,然后将该记录的删除flag隐藏字段设置为1,这样回滚后该记录的删除flag隐藏字段就又变回0了,相当于删除的数据又恢复了。
  2. 新插入的记录是没有历史版本的,但是一般为了回滚操作,新插入的记录也需要拷贝一份放入undo log中,只不过被拷贝到undo log中的记录的删除flag隐藏字段被设置为1,这样回滚后就相当于新插入的数据就被删除了。

当前读 VS 快照读

  • 当前读:读取最新的记录,就叫做当前读。
  • 快照读:读取历史版本,就叫做快照读。

事务在进行增删查改的时候,并不是都需要进行加锁保护。事务对数据进行增删改的时候,操作的都是最新记录,即当前读,需要进行加锁保护。事务在进行select查询的时候,既可能是当前读也可能是快照读,如果是当前读,那也需要进行加锁保护,但如果是快照读,那就不需要加锁,因为历史版本不会被修改,也就是可以并发执行,提高了效率,这也就是MVCC的意义所在。

undo log中的版本链何时才会被清除?

  1. 在undo log中形成的版本链不仅仅是为了进行回滚操作,其他事务在执行过程中也可能读取版本链中的某个版本,也就是快照读。
  2. 因此,只有当某条记录的最新版本已经修改并提交,并且此时没有其他事务与该记录的历史版本有关了,这时该记录在undo log中的版本链才可以被清除。

说明一下:

  1. 对于新插入的记录来说,没有其他事务会访问它的历史版本,因此新插入的记录在提交后就可以将undo log中的版本链清除了。
  2. 因此版本链在undo log中可能会存在很长时间,尤其是有其他事务和这个版本链相关联的时候,但这也没有坏处,这说明它是一个热数据。

Read View

事务在进行快照读操作时会生成读视图 Read View,在该事务执行快照读的那一刻,会生成数据库系统当前的一个快照,记录并维护系统当前活跃的事务ID。Read View在MySQL源码中就是一个类,本质是用来进行可见性判断的,当事务对某个记录执行快照读的时候,对该记录创建一个Read View,根据这个Read View来判断,当前事务能够看到该记录的哪个版本的数据。

class ReadView {// 省略...
private:/** 高水位:大于等于这个ID的事务均不可见*/trx_id_t m_low_limit_id;/** 低水位:小于这个ID的事务均可见 */trx_id_t m_up_limit_id;/** 创建该 Read View 的事务ID*/trx_id_t m_creator_trx_id;/** 创建视图时的活跃事务id列表*/ids_t m_ids;/** 配合purge,标识该视图不需要小于m_low_limit_no的UNDO LOG,* 如果其他视图也不需要,则可以删除小于m_low_limit_no的UNDO LOG*/trx_id_t m_low_limit_no;/** 标记视图是否被关闭*/bool m_closed;// 省略...
};

部分成员说明:

  1. m_ids: 一张列表,记录Read View生成时刻,系统中活跃的事务ID。
  2. m_up_limit_id: 记录m_ids列表中事务ID最小的ID。
  3. m_low_limit_id: 记录Read View生成时刻,系统尚未分配的下一个事务ID。
  4. m_creator_trx_id: 记录创建该Read View的事务的事务ID。

由于事务ID是单向增长的,因此根据Read View中的m_up_limit_id和m_low_limit_id,可以将事务ID分为三个部分:

  • 事务ID小于m_up_limit_id的事务,一定是生成Read View时已经提交的事务,因为m_up_limit_id是生成Read View时刻系统中活跃事务ID中的最小ID,因此事务ID比它小的事务在生成Read View时一定已经提交了。
  • 事务ID大于等于m_low_limit_id的事务,一定是生成Read View时还没有启动的事务,因为m_low_limit_id是生成Read View时刻,系统尚未分配的下一个事务ID。
  • 事务ID位于m_up_limit_id和m_low_limit_id之间的事务,在生成Read View时可能正处于活跃状态,也可能已经提交了,这时需要通过判断事务ID是否存在于m_ids中来判断该事务是否已经提交。

在这里插入图片描述

  • 一个事务在进行读操作时,只应该看到自己或已经提交的事务所作的修改,因此我们可以根据Read View来判断当前事务能否看到另一个事务所作的修改。
  • 版本链中的每个版本的记录都有自己的DB_TRX_ID,即创建或最近一次修改该记录的事务ID,因此可以依次遍历版本链中的各个版本,通过Read View来判断当前事务能否看到这个版本,如果不能则继续遍历下一个版本。

源码策略 如下:

bool changes_visible(trx_id_t id, const table_name_t& name) const MY_ATTRIBUTE((warn_unused_result))
{ut_ad(id > 0);//1、事务id小于m_up_limit_id(已提交)或事务id为创建该Read View的事务的id,则可见if (id < m_up_limit_id || id == m_creator_trx_id) {return(true);}check_trx_id_sanity(id, name);//2、事务id大于等于m_low_limit_id(生成Read View时还没有启动的事务),则不可见if (id >= m_low_limit_id) {return(false);}//3、事务id位于m_up_limit_id和m_low_limit_id之间,并且活跃事务id列表为空(即不在活跃列表中),则可见else if (m_ids.empty()) {return(true);}const ids_t::value_type* p = m_ids.data();//4、事务id位于m_up_limit_id和m_low_limit_id之间,如果在活跃事务id列表中则不可见,如果不在则可见return (!std::binary_search(p, p + m_ids.size(), id));
}

使用该函数时将版本的DB_TRX_ID传给参数id,该函数的作用就是根据Read View,判断当前事务能否看到这个版本。


RR 与 RC 的本质区别

启动两个终端,将隔离级别都设置为可重复读,并查看此时银行用户表中的数据。如下:

在这里插入图片描述

在两个终端各自启动一个事务,在左终端中的事务操作之前,先让右终端中的事务查看一下表中的信息。如下:

在这里插入图片描述

左终端中的事务对表中的信息进行修改并提交,右终端中的事务看不到修改后的数据。如下:

在这里插入图片描述

在右终端中使用 select ... lock in share mode 命令进行当前读,可以看到表中的数据确实是被修改了,只是右终端中的事务看不到而已。如下:

在这里插入图片描述

但如果修改一下SQL的执行顺序,在两个终端各自启动一个事务后,直接让左终端中的事务对表中的信息进行修改并提交,然后再让右终端中的事务进行查看,这时右终端中的事务就直接看到了修改后的数据。如下:

在这里插入图片描述

在右终端中使用select ... lock in share mode命令进行当前读,可以看到刚才读取到的确实是最新的数据。如下:

在这里插入图片描述

  • 上面两次实验的唯一区别在于,右终端中的事务在左终端中的事务修改数据之前是否进行过快照读。
  • 由于RR级别下要求事务内每次读取到的结果必须是相同的,因此事务首次进行快照读的地方,决定了该事务后续快照读结果的能力

RR与RC的本质区别

  • 正是因为Read View生成时机的不同,从而造成了RC和RR级别下快照读的结果的不同。
  • 在RR级别下,事务第一次进行快照读时会创建一个Read View,将当前系统中活跃的事务记录下来,此后再进行快照读时就会直接使用这个Read View进行可见性判断,因此当前事务看不到第一次快照读之后其他事务所作的修改。
  • 而在RC级别下,事务每次进行快照读时都会创建一个Read View,然后根据这个Read View进行可见性判断,因此每次快照读时都能读取到被提交了的最新的数据。
  • RR级别下快照读只会创建一次Read View,所以RR级别是可重复读的,而RC级别下每次快照读都会创建新的Read View,所以RC级别是不可重复读的。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/604218.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

神经网络中参数与超参数的区别是什么?

在神经网络中&#xff0c;参数和超参数是两个非常重要但概念上不同的元素。它们的主要区别在于它们在模型训练和构建中的角色和如何被确定。 参数&#xff08;Parameters&#xff09; 定义&#xff1a;参数是神经网络在训练过程中学习的变量。这些包括权重&#xff08;weights…

Rust-vec!与Vec::with_capacity初始化数组的区别

前言 这篇文章的实际上是对我在知乎上&#xff0c;下面这个问题的答案补充。 Rust能不能动态生成固定大小的数组&#xff08;array&#xff09;&#xff1f; 对于问题中的代码 fn main(){let n 3;let mut arr:[i32; n] [0;n] ; println!(":?", arr); }进行如下…

System学习笔记 - MacOs编译环境配置(一)

前言 好几年没有记录过东西&#xff0c;一是确实很忙&#xff0c;二是人也变懒了。新年开个新的学习计划&#xff0c;希望能坚持下去。 SystemC 简介 SystemC是一个建模语言&#xff0c;其本质是一个C的库&#xff0c;一般用于SoC建模&#xff0c;具体介绍不赘述&#xff0…

【学习记录】找最低位1/模块多次例化

一、找最低位1 要求&#xff1a;找出Nbit数据a中最低位1所在的位置&#xff0c;用onehot形式data_onehot表示 假设a1010_0100 将a减1&#xff0c;则可得最低位1后面所有数据为0的b,b1010_0011将b取反&#xff0c;得c,c0101_1100将a与c进行与操作&#xff0c;则可得 a&c 0…

CEEMDAN +组合预测模型(Transformer - BiLSTM+ ARIMA)

目录 往期精彩内容&#xff1a; 前言 1 风速数据CEEMDAN分解与可视化 1.1 导入数据 1.2 CEEMDAN分解 2 数据集制作与预处理 3 基于CEEMADN的 Transformer - BiLSTM 模型预测 3.1 定义CEEMDAN-Transformer - BiLSTM预测模型 3.2 设置参数&#xff0c;训练模型 4 基于A…

【Python学习】Python学习6-循环语句

目录 【Python学习】【Python学习】Python学习6-循环语句 前言for循环for循环示例通过序列索引迭代循环使用 else 语句 while循环while循环示例continue和 break无限循环循环使用 else 语句简单语句组 嵌套循环Python for 循环嵌套语法&#xff1a;Python while 循环嵌套语法&…

网络安全—IPSec安全策略

文章目录 网络拓扑添加策略ESP添加筛选器添加筛选器的操作另一台主机设置 AH 使用Windows Server 2003系统 网络拓扑 client1 IP 192.168.17.105client2 IP 192.168.17.106 只要保证两个主机在同一网段接口&#xff0c;即互相ping通即可完成策略的实现 下面的所有通讯都只是…

阿里云服务器ECS入门与基础运维

一、云服务器简介 1、服务器&#xff1a; (1) 概念&#xff1a; 服务器本身就是一种电脑&#xff0c;同样具备CPU、内存、硬盘、网卡、电源等硬件。 互联网对外提供网站、游戏、在线会议、网盘等服务&#xff0c;都需要将这些互联网服务部署到服务器中。 (2) 特点&#xf…

C语言编译器(C语言编程软件)完全攻略(第二十六部分:C-Free使用教程(使用C-Free编写C语言程序))

介绍常用C语言编译器的安装、配置和使用。 二十六、C-Free使用教程&#xff08;使用C-Free编写C语言程序&#xff09; 1、安装C-Free 5.0 C-Free 是一款国产的Windows下的C/C IDE&#xff0c;最新版本是 5.0&#xff0c;整个软件才 14M&#xff0c;非常轻巧&#xff0c;安装…

shell编程学习(二)

变量的类型 预定义变量 $$ 当前进程PID $? 命令执行后的返回状态.0 为执行正确&#xff0c;非 0 为执行错误 $# 位置参数的数量 $* 所有位置参数的内容 …

前端性能优化之图像优化

图像优化问题主要可以分为两方面&#xff1a;图像的选取和使用&#xff0c;图像的加载和显示。 图像基础 HTTP Archive上的数据显示&#xff0c;网站传输的数据中&#xff0c;60%的资源都是由各种图像文件组成的&#xff0c;当然这些是将各类型网站平均的结果&#xff0c;单独…

Mysql SQL审核平台Yearning本地部署

文章目录 前言1. Linux 部署Yearning2. 本地访问Yearning3. Linux 安装cpolar4. 配置Yearning公网访问地址5. 公网远程访问Yearning管理界面6. 固定Yearning公网地址 前言 Yearning 简单, 高效的MYSQL 审计平台 一款MYSQL SQL语句/查询审计工具&#xff0c;为DBA与开发人员使用…

阿里云服务器公网带宽1M/3M/5M/10M/50M百兆下载速度表

阿里云服务器公网带宽上传和下载速度对照表&#xff0c;1M带宽下载速度是128KB/秒&#xff0c;为什么不是1M/秒&#xff1f;阿腾云atengyun.com分享阿里云服务器带宽1M、2M、3M、5M、6M、10M、20M、30M、50M、100M及200M等公网带宽下载和上传速度对照表&#xff0c;附带宽价格表…

C# Winform 在低DPI创建窗体后,在高DPI运行时,窗体会自动拉伸,导致窗体显示不全

C# Winform 在低DPI创建窗体后&#xff0c;在高DPI运行时&#xff0c;窗体会自动拉伸&#xff0c;导致窗体显示不全&#xff0c; 比如在分辨率为100% 的电脑创建C#项目&#xff0c;当运动到分辨率为125%的电脑运行时&#xff0c;后者运行的窗体会自动拉伸&#xff0c;窗体显示…

【linux学习笔记】网络

目录 【linux学习笔记】网络检查、监测网络ping-向网络主机发送特殊数据包traceroute-跟踪网络数据包的传输路径netstat-检查网络设置及相关统计数据 【linux学习笔记】网络 检查、监测网络 ping-向网络主机发送特殊数据包 最基本的网络连接命令就是ping命令。ping命令会向指…

Java二叉树的遍历以及最大深度问题

Java学习面试指南&#xff1a;https://javaxiaobear.cn 1、树的相关概念 1、树的基本定义 树是我们计算机中非常重要的一种数据结构&#xff0c;同时使用树这种数据结构&#xff0c;可以描述现实生活中的很多事物&#xff0c;例如家谱、单位的组织架构、等等。 树是由n&#…

VMware中找到存在但是不显示的虚拟机(彻底发现)VMware已创建虚拟机不显示

删除VMware中的虚拟机的时候&#xff0c;可能没有把虚拟机完全删除&#xff0c;或者说 “移除” 后找不到虚拟机在哪里&#xff0c;内存空间也没有得到释放&#xff0c;那该如何解决呢&#xff1f; 1.明确&#xff1a; “移除” 不等于 “从磁盘删除” 移除&#xff1a;只…

【IPC通信--socket套接字--心跳包】

Socket 心跳包 提高网络通信稳定性 随着网络通信技术的不断发展&#xff0c;网络通信已成为我们日常工作和生活中不可或缺的一部分。但是在使用网络通信的过程中&#xff0c;时常会遇到网络延迟、丢包等问题&#xff0c;这些问题不仅影响我们的工作和生活效率&#xff0c;也会…

【Pytorch】学习记录分享14——视频分析3D卷积

【Pytorch】学习记录分享14——视频分析3D卷积 1. 视频分析 3D卷积2. UCF101数据3. U3D算法 1. 视频分析 3D卷积 3D卷积的简介 在图像处理领域&#xff0c;被卷积的都是静态图像&#xff0c;所以使用2D卷积网络就足以。而在视频理解领域&#xff0c;为了同时保留时序信息&…

解决DolphinDB vscode插件重启后无法访问的问题

把vscode的代理关掉&#xff1a; 左下角小齿轮&#xff0c;打开setting搜索框里搜索proxy将Http:Proxy Support从override改为off&#xff0c;即可生效