1、数据库事务概述
事务时数据库区别于文件系统的重要特性之一,当我们有了事务就会让数据库始终保持一致性
,同时我们还能通过事务的机制恢复到某个时间点
,这样可以保证已提交到数据的修改不会因为系统崩溃而丢失。
1.1 存储引擎支持情况
SHOW ENGINES
命令来查看当前 MySQL 支持的存储引擎都有哪些,以及这些存储引擎是否支持事务
能看出在 MySQL 中,只有InnoDB 是支持事务的
1.2 基本概念
事务:一组逻辑操作单元,使数据从一种状态变换到另外一种状态。
==事务处理的原则:==保证所有事务都作为一个工作单元
来执行,即使出现了故障,都不能改变这种执行方式。当在一个事务中执行多个操作时,要么所有的事务都被提交(commit),那么这么修改就永远地保存下来了;要么数据库管理系统将放弃
所作的所有修改
,整个事务回滚(rollback)到最初状态。
# 案例 AA 用户 给BB 用户 转账100
update account set money = money -100 where name = 'AA';
#服务器宕机
update account set money = money +100 where name = 'BB';
1.3 事务ACID特性
- 原子性(atomicity)
原子性是指事务是一个不可分割的工作单位,要么全部提交,要么全部失败回滚。即要么转账成功,要么转账失败,不存在中间状态。如果无法保证原子性会怎么样?就会出现数据不一致的情形,A账户减去100元,而B账户增加100元操作失败,系统将无故丢失100元。
- 一致性(consistency)
根据定义,一致性是 指事务执行前后,数据从一个合法性状态
变换到另外一个合法性状态
。这种状态是语义上
的而不是语法上的,跟具体业务有关。
那什么是合法的数据状态呢?
满足预定的约束
的状态就是合法的状态。
通俗一点,这状态是由你自己来定义的(比如现实世界的约束)。满足这个状态,数据就是一致的,不满足这个状态,数据就是不一致的!如果某个事务中的某个操作失败了,系统就会自动撤销当前正在执行的事务,返回到事务操作之前的状态。
举例1:A账户有200元,转账出去300元,此时A账户余额为-100元。你自然就 发现了 此时数据是不一致的,为什么?因为你定义了一个状态,余额这列必须 >=0
举例2:A账户200元,转账50元给B,A账户的钱扣了,但是B账户因为各种意外,余额并没有增加。你也知道此时数据是不一致的,为什么呢?因为你定义了一个状态,要求A+B的总余额必须不变。
举例3:在数据表中我们将姓名
字段设置为唯一性约束
,这时当事务进行提交或者事务发生回滚的时候,如果数据表中的姓名不一致,就破坏了事务一致性的要求。
- 隔离性(isolation)
事务的隔离性是指一个事务的执行不能被其他事务所干扰
,即一个事务内部的操作及使用的数据对并发
的其他事务时隔离的,并发执行的各个事务之间不能互相干扰。
无法保证隔离性会怎么样?
假设A账户有200元,B账户有0元,A往B转账两次,每次金额为50元,分别在两个事务中执行。如果无法保证隔离性,会出现下面的情形:
- 持久性(durability)
持久性是指一个事务一旦被提交,对数据库做出的改变就是永久性的,接下来的其他操作和数据库故障不应该对其有任何影响。
持久性时通过事务日志
来保证的。日志包括了重做日志
和回滚日志
。当我们通过事务对数据进行修改的时候,首先会将数据库的变化信息记录到重做日志中,然后再对数据库中对应的行进行修改。这样作的好处是,即使数据库系统崩溃,数据库重启后也能找到没有更新到数据库系统中的重做日志,重新执行,从而使事务具有持久性。
1.4 事务的状态
我们现在知道 事务
是一个抽象的概念,它其实对应着一个或多个数据库操作,MySQL根据这些操作所执行的不同阶段把 事务 大致划分成几个状态:
- 活动的(active)
事务对应的数据库操作正在执行过程中时,我们就说该事务处在 活动的 状态。
- 部分提交的(partially committed)
当事务中的最后一个操作执行完成,但由于操作都在内存中执行,所造成的影响并 没有刷新到磁盘时
,我们就说该事务处在 部分提交的
状态
- 失败的(failed)
当事务处在活动的
或者是部分提交的
状态时,可能遇到了某些错误(数据库自身的错误,操作系统错误或者直接断电等)而无法继续执行,或者人为的停止当前事务的执行,我们就说该事务处在失败的状态
- 中止的(aborted)
如果事务执行了一部分而变为 失败的
状态,那么就需要把已经修改的事务中的操作还原到事务执行前的状态。换句话说,就是要撤销失败事务对当前数据库造成的影响。
我们把这个撤销的过程称之为 回滚
。当 回滚
操作执行完毕时,也就是数据库恢复到了执行事务之前的状态,我们就说该事务处在了 中止的
状态。
- 提交的(committed)
当一个处在 部分提交的
状态的事务将修改过的数据都 同步到磁盘
上之后,我们就可以说该事务处在了 提交的
状态
一个基本的状态转换图如下所示:
2、如何使用事务
使用事务有两种方式,分别为 显式事务
和 隐式事务
2.1 显式事务
步骤1: START TRANSACTION
或者 BEGIN
,作用是显式开启一个事务
mysql> BEGIN;
#或者
mysql> START TRANSACTION;
START TRANSACTION
语句相较于 BEGIN
特别之处在于,后边能跟随几个 修饰符
:
1、read only
:标识当前事务是一个只读事务
,也就是属于该事务的数据库操作只能读取数据,而不能修改数据
补充:只读事务中是不允许修改那些其他事务也能访问到的表中的数据,对于临时表来说(我们使用create tmeporary table 创建的表),由于它们只能在当前会话中可见,所以只读事务其实也是可以对临时表进行增、删、改的
2、read write
:标识当前事务时一个读写事务
,也就是属于该事务的数据库操作既可以读取数据,也可以修改数据
3、with consistent snapshot
:启动一致性读
start transaction read only; #开启一个只读事务
start transaction read only , with consistent snapshot; #开启只读事务和一致性读
start transaction read write , with consistent snapshot; #开启读写事务和一致性读
注意:
- read only 和 read write 使用来设置所谓的事务
访问模式
的,就是以只读还是读写的方式来访问数据库中的数据,一个事务的访问模式不能同时既设置为只读
的也设置为读写
的,所以不能同时把read only
和read write
放到start transaction
语句后面 - 如果我们不显示的指导事务的访问模式,那么改事务就是
读写模式
步骤2:
一系列事务中的操作(主要是DML,不含DDL)
步骤3:
提交事务 或 中止事务(即回滚事务)
# 提交事务 当提交事务后,对数据库的修改是永久性的
mysql > COMMIT;
# 回滚事务。即撤销正在进行的所有没有提交的修改
mysql > ROLLBACK;
#将事务回滚到某个保存点
mysql > ROLLBACK TO [SAVEPOINT]
其中关于savepoint的相关操作有
# 在事务中创建保存点,方便后续针对保存点进行回滚。一个事务中可以存在多个保存点
savepoint 保存点名称;
# 删除某个保存点
release savepoint 保存点名称
2.2 隐式事务
MySQL中有一个系统变量 autocommit
SHOW VARIABLES LIKE 'autocommit';
默认是开启自动提交事务的
我们如果想关闭这种自动提交
的功能,可以使用下面2种方法
- 显示的使用
start transaction
或者begin
语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能 - 把系统变量
autocommit
的值设置为OFF
这样的话,我们写入的多条语句就属于同一个事务了,直到我们显式的写出commit
语句来把这个事务提交掉,或者显示的rollback
语句来把这个事务回滚掉。
补充:Oracle默认不自动提交,需要手写commit命令,而Mysql默认自动提交
2.3 隐式提交数据的情况
- 数据库定义语言(DDL)
数据库对象,指的就是数据库、表、视图、存储过程等结构。
当我们使用create
、alter
、drop
等语句去修改数据库对象时,就会隐式的提交前边语句所属于的事务。即:
BEGIN;
select ...
update ... #事务中的语句
create table .... #此语句会隐式的提交前边语句所属于的事务
- 隐式使用或修改mysql 数据库中的表
当我们使用 alter user
、create user
、drop user
、grant
、rename user
、remove
、set
、password
等语句时也会隐式的提交前边语句所属于的事务。
- 事务控制或关于锁定的语句
1、当我们在一个事务还没提交或者回滚时就又使用start transaction
或者begin
语句开启了另一个事务时,会隐式的提交
上一个事务。即
BEGIN;
select ...
update ... #事务中的语句
BEGIN; # 此语句会隐式的提交前面语句所属于的事务
2、当前autocommit
系统变量的值为OFF
,我们手动把它调为ON时,也会隐式的提交
前边语句所属的事务。
3、使用lock tables
、unlock tables
等关于锁定的语句也会隐式的提交
前边语句所属的事务
- 加载数据的语句
使用load data
语句来批量往数据库中导入数据时,也会隐式的提交
前面语句所属的事务。
- 关于Mysql复制的一些语句
使用start slave
、stop slave
、reset slave
、change master to
等语句会隐式提交
前面语句的事务
- 其他的一些语句
2.4 completion_type 参数
1、completion = 0,默认情况,当我们执行commit的时候会提交事务,在执行下一个事务时,还需要使用start transaction
或者begin来开启
2、completion = 1,这种情况下,当我们提交事务后,相当于执行了 commit and chain ,也就是开启一个链式事务,即当我们提交事务之后会开启一个相同隔离级别 的事务。
3、completion = 2,这种情况下 commit = commit and release,也就是当我们提交后,会自动与服务器断开连接。
当我们设置 autocommit=0 时,不论是否采用 START TRANSACTION 或者 BEGIN 的方式来开启事务,都需要用 COMMIT 进行提交,让事务生效,使用 ROLLBACK 对事务进行回滚
当我们设置 autocommit=1 时,每条 SQL 语句都会自动进行提交。 不过这时,如果你采用 START TRANSACTION 或者 BEGIN 的方式来显式地开启事务,那么这个事务只有在 COMMIT 时才会生效,在 ROLLBACK 时才会回滚。
3、事务的隔离级别
MySQL是一个 客户端/服务器
架构的软件,对于同一个服务器来说,可以有若干个客户端与之连接,每个客户端与服务器连接上之后,就可以称为一个会话( Session )。
每个客户端都可以在自己的会话中向服务器发出请求语句,一个请求语句可能是某个事务的一部分,也就是对于服务器来说可能同时处理多个事务。
事务有 隔离性
的特性,理论上在某个事务 对某个数据进行访问 时
,其他事务应该进行 排 队
,当该事务提交之后,其他事务才可以继续访问这个数据。
但是这样对 性能影响太大
,我们既想保持事务的隔离性
,又想让服务器在处理访问同一数据的多个事务时 性能尽量高些
,那就看二者如何权衡取舍
了
3.1 数据准备
我们需要创建一个表:
CREATE TABLE student (
studentno INT,
NAME VARCHAR (20),
class VARCHAR (20),
PRIMARY KEY (studentno)
) ENGINE = INNODB CHARSET = utf8;
然后向这个表里插入一条数据:
INSERT INTO student VALUES(1, '小谷', '1班');
3.2 数据并发问题
针对事务的隔离性和并发性,我们怎么做取舍呢?先看一下访问相同数据的事务在 不保证串行执行
(也就是执行完一个再执行另一个)的情况下可能会出现哪些问题:
1、脏写(Dirty Write)
对于两个事务 Session A、Session B,如果事务Session A 修改了 另一个 未提交 事务Session B 修改过 的数据,那就意味着发生了 脏写
2、脏读(Dirty Read)
对于两个事务 Session A、Session B,Session A 读取 了已经被 Session B 更新 但还 没有被提交
的字段。之后若 Session B 回滚
,Session A 读取 的内容就是临时且无效
的。
3、不可重复读(Non-Repeatable Read)
对于两个事务Session A,Session B。Session A读取了一个字段,然后Session B修改了这个字段,然后Session A,再次去读
同一个字段,值就不同了。那就意味着发生了不可重复读。
我们在Session B中提交了几个隐式事务
(注意是隐式事务,意味着语句结束,事务会自动提交),这些事务都修改了studentno列为1的记录的name字段的值,每次提交事务后,如果Session A中的事务都可以查到最新的值,这种现象称作为不可重复读
。
4、幻读(Phantom)
对于两个事务SessionA,SessionB,SessionA从一个表中读取
了一个字段,然后Session B在该表中插入
了一些新的行。之后,如果Session A再次读取
同一个表,就会多出几行。这就意味着发生了幻读。
Session A中的事务先根据条件 studentno > 0这个条件查询表student,得到了name列值为’张三’的记录;
之后Session B中提交了一个 隐式事务
,该事务向表student中插入了一条新记录;
之后Session A中的事务再根据相同的条件 studentno > 0查询表student,得到的结果集中包含Session B中的事务新插入的那条记录,这种现象也被称之为 幻读
。我们把新插入的那些记录称之为 幻影记录
注意1:
那如果Session B中删除了一些符合studentno > 0的记录,而不是插入新记录,那Session A之后再根据 studentno > 0的条件读取的记录变少了
,这种现象算不算幻读呢?
这种不算幻读,幻读强调的是一个事务按照某个相同条件多次读取
记录时,后读取时读到了原来没有读到的记录。
注意2:
那对于先前已经读到的记录,之后又读取不到这种情况,算啥呢?这相当于对每条记录都发生了不可重复读
的现象。
幻读只是重点强调读取到了之前没有读取到的记录。
3.3 SQL的四种隔离级别
按问题严重排序
脏写 > 脏读 > 不可重复读 > 幻读
我们愿意舍弃一部分隔离性来换取一部分性能在这里就体现在:
设立一些隔离级别,隔离级别越低,并发问题发生的就越多。 SQL标准 中设立了4个 隔离级别
:
-
READ UNCOMMITTED
:读未提交,在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读 -
READ COMMITTED
:读已提交,它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别,但不是MySQL默认的。可以避免脏读,但不可重复读、幻读问题仍然存在 -
REPEATABLE READ
:可重复读(Mysql默认隔离级别),事务A在读到一条数据之后,此时事务B对该数据进行了修改并提交,那么事务A再读该数据,读到的还是原来的内容。可以避免脏读、不可重复读,但幻读问题仍然存在。这是MySQL的默认隔离级别 -
SERIALIZABLE
:可串行化,确保事务可以从一个表中读取相同的行。在这个事务持续期间,禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免,但性能十分低下。能避免脏读、不可重复读和幻读SQL标准 中规定,针对不同的隔离级别,并发事务可以发生不同严重程度的问题,具体情况如下
脏写
怎么没涉及到?因为脏写这个问题太严重了,不论是哪种隔离级别,都不允许脏写的情况发生
不同的隔离级别有不同的现象,并有不同的锁和并发机制,隔离级别越高,数据库的并发性能就越差,4种事务隔离级别与并发性能的关系如下:
3.4 Mysql支持的四种隔离级别
MySQL的默认隔离级别为REPEATABLE READ(可重复读),我们可以手动修改一下事务的隔离级别
查看隔离级别
# 5.7
SHOW VARIABLES LIKE 'tx_isolation';
# 8.0
SHOW VARIABLES LIKE 'transaction_isolation';
3.5 如何设置事务的隔离级别
通过下面的语句修改事务的隔离级别:
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL 隔离级别;
#或者:
SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = '隔离级别'
#其中,隔离级别格式:
READ UNCOMMITTED; #读未提交
READ COMMITTED; #读已提交
REPEATABLE READ; #重复读
SERIALIZABLE; #串行化
关于设置时使用GLOBAL或SESSION的影响:
- 使用 GLOBAL 关键字(在全局范围影响)
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
#或者
SET GLOBAL TRANSACTION_ISOLATION = 'SERIALIZABLE';
则:
1、当前已经存在的会话无效 2、只对执行完该语句之后产生的会话起作用
- 使用 SESSION 关键字(在会话范围影响)
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
#或者
SET SESSION TRANSACTION_ISOLATION = 'SERIALIZABLE';
则:
1、对当前会话后续的事务有效 2、如果在事务之间执行,则对后续事务有效
3、该语句可以在已经开启的事务中间执行,但不会影响正在执行的事务
小结:
数据库规定了多种事务隔离级别,不同隔离级别对应不同的干扰程度,隔离级别越高,数据一致性就越好,但并发性就越弱。
3.6 不同隔离级别举例
演示1:读未提交之脏读
1、先将事务1,事务2的会话隔离级别设置成读未提交
2、会话1,开启事务1,查询account的数据
3、会话2,开启事务2,执行修改sql,将id=2的用户加上100块钱。(此时未提交事务2)
BEGIN;
UPDATE account SET balance = balance + 100 WHERE id =2;
4、事务1再去查询account的数据
5、发现事务1读到了事务2未提交的数据,我们将事务2回滚,发现id=2的用户的balance值又变成100了。
这就是出现了 读未提交隔离级别下的 脏读,一个事务读到了另一个事务未提交的数据。
演示2:读已提交
读已提交,能解决脏读问题,但是会出现不可重读的问题,同一事务,前后两次读取到的数据不同了。
演示3:可重复读
设置隔离级别为可重复读,事务的执行流程如下:
(默认级别:可重复读,就解决了不可重复读的问题) ,但是会出现幻读的情况。
演示4:幻读
虽然看不到(因为解决了不可重复读嘛),但是,不能新增主键重复的值了,确实影响到了事务1。
幻读,并不是说两次读取的结果集不同,幻读侧重的方面是某一次的select操作得到的结果所表征的数据状态无法支撑后续的业务操作。
更为具体一些就是:select某记录是否存在,不存在,准备去插入此记录,但是执行insert 的时候 发现此记录已经存在了,无法插入,此时就发生了幻读。(前后操作不一致,明明不存在,为什么会插入失败呢?就好像发生了幻觉一样)
在RR隔离级别下,step1、step2是会正常执行的,step3则会报错主键冲突,对于事务1的业务来说是执行失败的,这里事务1就是发生了幻读,因为事务1在step1中读取的数据状态并不能支撑后续业务的操作。
事务1:见鬼了,我刚才读到的结果应该可以支持我的insert操作才对啊,为什么现在不可以呢?事务1不敢相信又执行了一次step4,发现和step1读取的结果是一样的(可重复读下面的MVCC机制)。此时,幻读无疑已经发生,事务1无论读取多少次,都查不到 id =3 的记录,但它的确插入这条他通过读取来认定不存在的记录(此数据已被事务2插入),对于事务1来说,它幻读了。
其实可重复读是可以避免幻读的。
通过对select 操作手动加 行X锁(独占锁)
,( select … for update 这也是 串行化 隔离级别下隐式会给你做的事情 )。同时,即使当前记录不存在,比如id=3是不存在的,当前 事务也会获得一把记录锁(因为InnoDB的行锁锁定的是索引,故记录实体存在与否没关系,存在就加行X锁
,不存在就加间隙锁
),其他事务则无法插入此索引的记录 ,故杜绝了幻读。
在串行话隔离级别下,step1执行时会隐式的添加(行占锁)/gap(X锁),从而step2会被阻塞,step3会正常执行,待事务1提交后,事务2才能继续执行(主键冲突执行失败),对于事务1来说是正确的。成功的阻塞扼杀了扰乱业务事务2,对事务1来说他前期的读取结果是可以支持后续业务的。
所以Mysql的幻读并不是说读取两次结果集返回不同,而是事务在插入事前检测不存在的记录,惊奇的发现这些数据已经存在了,之前的检测获取到的数据跟个鬼一样。