Mysql专栏:@Mysql
本篇博客简介:介绍mysql的事务
mysql的事务
- 事务的概念
- 事务功能测试
- 事务的隔离级别
- 如何理解隔离性(粗浅理解)
- 隔离级别
- 查看和设置隔离级别
- 四种隔离级别详解
- 读 -- 未提交
- 读 - 提交
- 可重复读
- 串行化
- 一致性的理解
- 总结
事务的概念
事务就是一组DML语句组成,这些语句在逻辑上存在相关性,这一组DML语句要么全部成功,要么全部失败,是一个整体。MySQL提供一种机制,保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。
事务就是要做的或所做的事情,主要用于处理操作量大,复杂度高的数据。假设一种场景:你毕业了,学校的教务系统后台 MySQL 中,不在需要你的数据,要删除你的所有信息(一般不会:) ), 那么要删除你的基本信息(姓名,电话,籍贯等)的同时,也删除和你有关的其他信息,比如:你的各科成绩,你在校表现,甚至你在论坛发过的文章等。这样,就需要多条 MySQL 语句构成,那么所有这些操作合起来,就构成了一个事务。
正如我们上面所说,一个 MySQL 数据库,可不止你一个事务在运行,同一时刻,甚至有大量的请求被包装成事务,在向 MySQL 服务器发起事务处理请求。而每条事务至少一条 SQL ,最多很多 SQL ,这样如果大家都访问同样的表数据,在不加保护的情况,就绝对会出现问题。甚至,因为事务由多条 SQL 构成,那么,也会存在执行到一半出错或者不想再执行的情况,那么已经执行的怎么办呢?
这个时候我们是不是应该就回滚到没有执行时的状态
事务的四个属性
所有,一个完整的事务,绝对不是简单的 sql 集合,还需要满足如下四个属性:
- 原子性:一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
- 一致性:在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 隔离性:数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交( Readuncommitted )、读提交( read committed )、可重复读( repeatable read )和串行化( Serializable )
- 持久性:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
上面四个属性,可以简称为 ACID 。
- 原子性(Atomicity,或称不可分割性)
- 一致性(Consistency)
- 隔离性(Isolation,又称独立性)
- 持久性(Durability)
事务的作用
事务被 MySQL 编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的.
支持事务的引擎
我们可以通过 show engines
指令来查看支持事务的引擎
可以看到的是 在mysql中 只有innodb支持事务
事务的提交方式
事务的提交方式常见的有以下两种
- 自动提交
- 手动提交
我们使用 show variables like ‘autocommit’
可以查看默认的事务提交方式
此外我们可以使用set
指令来改变事务的提交方式
当我们将autocommit设置为0的时候自动提交关闭 设置为1的时候自动提交开启
事务功能测试
(第一次看到下面这些专业名词的时候 一些读者可能会一脸懵 不知道在说什么 但是看完整篇博客之后再回过来看就会理解了)
读–未提交测试
首先我们要设置以下事务的隔离级别 设置语法如下
set global translation isolation level read uncommitted;
退出mysql重新登录之后我们可以使用 select @@tx_isolation
指令来查看隔离级别
演示一: 事务的开始 回滚 提交
首先我们需要创建一个测试表
此时我们创建两个mysql客户端 一个开始运行事务 一个负责查看变化
事务启动的命令是 begin
我们发现 在一个客户端事务中进行的所有数据都能够被另一个客户端所看到
此时我们在这里设置一个回滚点 之后插入一个新的数据
如果我们觉得这个数据不需要 还想要上面的一个版本 那么直接回滚到上个回滚点就好
当然 如果想回滚到事务刚开始的状态则直接使用rollback
指令即可
演示二:开启事务后客户端崩溃
之后我们左边开始向account表中插入事务
插入数据之后我们可以发现右边的客户端也可以看到数据
之后我们使用信号让左边客户端强制中断 之后再次用右边的客户端查看数据
我们可以发现 account表中的数据不见了 这个现象实际上说明了三点
- 事务是原子性的 要么完成 要么未完成 没有中间状态
- 如果一个事务在运行的过程中被终端了 那么它会回滚到最开始的版本
- 自动提交和手动开启的事务没有关系
演示三: 单条sql语句和事务的关系
首先我们将自动提交关闭
之后使用单条sql语句向account表中插入数据 并在另一个客户端查看
此时我们发现 就算我们没有开启事务 使用单条sql语句插入之后中断客户端 数据也会进行回滚 这是为什么呢?
其实我们的单条sql语句也是一个事务 只不过我们之前开启了自动提交 所以说每次执行完单条sql语句之后数据就自动提交并且持久化
而当我们关闭自动提交之后 如果没有手动commit而中断客户端 那么mysql就认为这是一个未完成的事务而直接回退到一开始的版本中了
事务的隔离级别
如何理解隔离性(粗浅理解)
- MySQL服务可能会同时被多个客户端进程(线程)访问,访问的方式以事务方式进行
- 一个事务可能由多条SQL构成,也就意味着,任何一个事务,都有执行前,执行中,执行后的阶段。而所谓的原子性,其实就是让用户层,要么看到执行前,要么看到执行后。执行中出现问题,可以随时回滚。所以单个事务,对用户表现出来的特性,就是原子性。
- 但毕竟所有事务都要有个执行过程,那么在多个事务各自执行多个SQL的时候,就还是有可能会出现互相影响的情况。比如:多个事务同时访问同一张表,甚至同一行数据。
- 数据库中,为了保证事务执行过程中尽量不受干扰,就有了一个重要特征:隔离性
- 数据库中,允许事务受不同程度的干扰,就有了一种重要特征:隔离级别
隔离级别
一共有四种隔离级别
- 读未提交【Read Uncommitted】: 在该隔离级别,所有的事务都可以看到其他事务没有提交的执行结果。(实际生产中不可能使用这种隔离级别的),但是相当于没有任何隔离性,也会有很多并发问题,如脏读,幻读,不可重复读等,我们上面为了做实验方便,用的就是这个隔离性。
- 读提交【Read Committed】 :该隔离级别是大多数数据库的默认的隔离级别(不是 MySQL 默认的)。它满足了隔离的简单定义:一个事务只能看到其他的已经提交的事务所做的改变。这种隔离级别会引起不可重复读,即一个事务执行时,如果多次 select, 可能得到不同的结果。
- 可重复读【Repeatable Read】: 这是 MySQL 默认的隔离级别,它确保同一个事务,在执行中,多次读取操作数据时,会看到同样的数据行。但是会有幻读问题。(mysql中解决了这个问题)
- 串行化【Serializable】: 这是事务的最高隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决了幻读的问题。它在每个读的数据行上面加上共享锁。但是可能会导致超时和锁竞争(这种隔离级别太极端,实际生产基本不使用)
为什么要有隔离级别
隔离级别实际上就是在效率和安全之间找到一个平衡点
而mysql之所以设置这么多隔离级别就是为了让用户有得选
脏读 幻读 不可重复读是什么意思
脏读: 一个事务在执行过程中读到了其他事务没有提交的数据
我们在上面的实验中肯定知道了一点 如果一个事务没有提交 那么它的数据是不一定会留下来的
那么我们读取了一个可能不会存在的数据 这肯定是一个问题
幻读: 一个事务在执行过程中读取了通过select读取了新的数据
一般来说我们加锁针对的是已存在的数据 所以说加锁之后 删改查 并不会有什么问题 但是对于不存在的数据我们无法加锁 也就是说我们无法保证是否有事务向数据库表中插入新的数据 如果说我们前后的select不一致(强调后面的select读取出了新的数据) 那么这个时候就是出现了幻读问题
mysql通过Next-Key锁(GAP+行锁)的形式解决了在可重复度隔离级别下的幻读问题
不可重复读: 一个事务在执行过程中多次读取的数据不一致的
这个问题主要出现在读提交隔离级别中 我们每次读取的时候都会受到别的事务提交数据的影响
查看和设置隔离级别
查看全局隔离级别
查看当前会话隔离级别
设置隔离级别
语法
--设置当前会话 or 全局隔离级别语法
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READCOMMITTED | REPEATABLE READ | SERIALIZABLE}
四种隔离级别详解
读 – 未提交
这是效率最高的一个隔离级别 也是安全性最差的一个隔离级别 平时我们不建议使用
下图两个客户端都被我们设置为了读–未提交隔离级别
之后我们让两个客户端同时查看一张表 一个客户端启动事务(不提交)向里面插入数据 一个客户端查看表
我们发现就算这个客户端没有提交数据 另外一个客户端还是能够看到数据 这个就是读未提交
读 - 提交
下图两个客户端都被我们设置为了读–提交隔离级别
之后我们左边客户端启动一个事务 并且插入一个数据之后 再使用右边的客户端查看数据 我们就会发现account数据表没有任何的变化
之后我们让右边的客户端开启一个事务 并且再次查询
之后左边commit 右边继续查询
我们发现当左边的客户端提交数据之后 右边再次查询读取了做百年新提交的数据 这也就造成了不可重复读的问题
可重复读
下面两个图中的客户端都被我们设置了可重复读隔离级别
之后我们同时启动两个事务
首先我们在右边的客户端中查询数据 之后让左边客户端插入数据之后提交 之后再次查看右边客户端的数据
我们发现此时右边客户端中的数据没有改变 还是一开始读取的那个 这就是可重复读
幻读问题
事实上我们刚刚的操作很可能会产生一个幻读问题 因为数据库只能对于存在的数据加锁 所以说插入的数据很可能会被再次select住
不过mysql通过Next-Key锁 (GAP+行锁)解决了这个问题 在使用其他数据库的时候我们仍然可能遇到
串行化
串行化是最安全 也是效率最低的一个模式
它直接暴力的将除了读以外的所有行为全部加锁 自然也就不会有安全上的问题了
这里就不作演示了
一致性的理解
一致性是由其他三个特性保证的 原因如下
- 事务执行的结果,必须使数据库从一个一致性状态,变到另一个一致性状态。当数据库只包含事务成功提交的结果时,数据库处于一致性状态。如果系统运行发生中断,某个事务尚未完成而被迫中断,而改未完成的事务对数据库所做的修改已被写入数据库,此时数据库就处于一种不正确(不一致)的状态。因此一致性是通过原子性来保证的。
- 事务处理结束之后必须要保证数据的保存是永久的 所以说一致性是通过持久性保证的
- 在多个事务并行的时候 不会由于交叉执行而导致数据不一致 所以说一致性是通过隔离性保证的
- 此外一致性还和用户的业务逻辑强相关 如果说用户的业务逻辑不正确就不能保证一致性