MySQL如果没有事务,究竟会发生什么?
一、从转账到事务解说
1、事务的概念:
我们先说个小故事:
平行世界里,某一对异地情侣boy和girl,boy有100块钱,girl有10块钱,现在boy想在给girl 手机转账50块钱,对应的数据库操作为:
UPDATE account SET balance = balance - 50 WHERE id = boy; # 1
UPDATE account SET balance = balance + 50 WHERE id = girl; # 2
只有操作1和2都共同完成的时候,boy的转账才算成功,可是,如何在执行了操作1之后,服务器突然断电了,操作2还没有执行。。。
这种情况就相当于从boy的账户里减了钱,但是girl的账户却没收到钱,这对情侣的总资金就变少了50,在他们看来那50块钱就像是不翼而飞了一样。
那数据库是怎么解决这种问题的呢?这就是我们即将要讲到的事务了。
“事务"不是某种客观存在的实体,而是一种逻辑操作的组合,这种组合的操作需符合ACID特性。
(1)、原子性(Atomicity) A
原子性取义于物理原子,原子是物质的最小单位,不可分割;原子性操作要么成功进入下一个状态,要么失败退回最初状态,不存在中间状态。
在我们现实生活中的转账,只有两种情况:要么转账成功,要么转账失败;无论是这里面的哪种情况转账双方的总资金是不变的;不存在上面提到平行世界中的那个例子——只转到一半。
很多在用户看来是单一操作的,在机器或者服务器看来就是很多条操作的组合(就像高级语句int i =0;对应的多条的二进制语句一样),原子性就是保证这些组合要么全执行,要么全不执行(退回执行前的状态)。
(2)、一致性(Consistency) C
这里的一致性是指数据库世界和现实世界规则的一致性,当然数据库里的规则当然没能和现实世界一一对应,毕竟现实世界的规则很多很多,比如身份证号不能重复,性别只有男和女,房价不能为负,高考分数最高是750等等。
也正因为这个的存在,数据库层面也出现了各种约束:主键约束、唯一约束、非空约束等。
一致性,比如一个高考生的成绩表中出现了751分,这种情况不用去核查都知道是数据错了,因为现实世界中高考成绩是不可能超过750的(最起码现在是这样)
(3)、隔离性(Isolation) I
假设前面提到的boy给girl转50块,分两次操作:第一次(T1)转30,第二次(T2)转20;但每一次转账都细分为6个步骤。
一般情况下,无论是先进行T1,还是T2,boy都可以成功转账50给girl的,毕竟30+20=50,20+30=50;但是实际上却没有这么简单,真实数据库中,T1和T2的操作可交替进行的(类比操作系统中的进程并发)。
经过上图的流程,最后我们惊讶地发现boy的账户由100变到了70,girl的账户由10变成了60;原来两人的总资金100+10=110,而现在70+60=130,现总资金比原总资金多了20。
这很明显就存在了问题,不然如果一直这样下去的话,所有人都去转账了,钱不少反而变多。
所以在数据库中,我们不仅要保持事务的原子性,还要隔离其他事务对某种事务的影响,使得其他的状态转换并不能影响该状态转换的结果,这就是隔离性。
(4)、持久性(Durability) D
持久性是指一旦状态转换成功后,该状态就被记录下来,无法回滚。
就好像boy给girl转30,一旦转成功之后,转账成功的状态就被永久记录下来了,不可逆,boy不可能单方面把30要回来的,当然如果是girl把30给回boy,这已经是另外一个过程了。
说了这么多,终于到了事务概念的总结了:
事务就是需要保持以上四种特性(ACID)的一系列数据库操作!
二、事务的状态及其转换
事务是一个抽象的概念,是一系列的数据库操作的集合,在它的执行过程中分为一下几种状态:
- 活动的:事务在正常执行。
- 部分提交的:事务操作已经完成,但是操作的结果只停留在内存中,还没有刷盘保存。
- 提交的:事务操作被刷盘之后。
- 失败的:只要事务无法刷新回磁盘都是失败的,数据库不允许不具有持久性的事务存在,又因为原子性,既然无法成功,那只能失败。
- 中止的:回滚,由中间状态回到初始状态。
三、MySQL中事务的基本操作
1、开启事务
BEGIN;
START TRANSACTION;
事务可以由以上两个语句开启,BEGIN和START TRANSACTION有相同的功效,都代表着一个事务的开启,但是START TRANSACTION后边可以加几个修饰符:
-
READ ONLY ,只读,标志着当前开启的事务是一个只读事务,只能读取数据,不能修改其实事务也能访问到的数据;但是可以修改临时表中的数据,临时表只存在当前会话,其他事务无法访问。 START TRANSACTION,READ ONLY ; -
READ WRITE ,读写,标志着当前开启的事务是一个读写事务,既可以读取数据,也可以修改数据。 START TRANSACTION,READ WRITE ; -
WITH CONSISTENT SNAPSHOT ,启用一致性读。 START TRANSACTION,WITH CONSISTENT SNAPSHOT;
若没显式指明事务的访问模式,则默认是READ WRITE,读写模式!
2、提交事务
BEGIN或START TRANSACTION开始的事务,一直到COMMIT结束。
COMMIT;
(1)自动提交
MySQL中有一个系统变量 autocommit ,默认是on开启的状态的,当我们不显式使用BEGIN或START TRANSACTION开始事务,则默认每一个语句都是一个事务,执行完毕后自动提交(受autocommit的状态影响)
(2)隐式提交
有些时候,在autocommit =off关闭的状态下,事务还是悄悄的被提交了,这种就是隐式提交。
下面列举几种常见的隐式提交的情况:
-
定义或修改数据库对象的数据定义语言(Data definition language,缩写为: DDL )。 数据库对象是指数据库 、 表 、 视图 、 存储过程 等 当我们使用CREATE 、ALTER 、 DROP 等DDl语句 去修改数据库对象的时候,这些语句就会被隐式提交(这时候是提交由事务开始到该语句的所有,并不是单单提交该语句;可以理解为这种情况下,该DDl语句等效与COMMIT)。 -
隐式使用或修改 mysql 数据库中的表 ALTER USER 、 CREATE USER 、 DROP USER 、 GRANT 、 RENAME USER 、 REVOKE 、 SET PASSWORD 等 -
两个开启事务语句之间 BEGIN; SELECT … # 事务中的一条语句 UPDATE … # 事务中的一条语句 … # 事务中的其它语句 BEGIN; # 此语句会隐式的提交前边语句所属于的事务
3、手动中止事务
事务是具有ACID特性的一系列数据库操作,当我们发现其中某条语句写错了的时候,可以手动中止事务,让事务回滚(回到某一状态)。
ROLLBACK; # 回滚到上一次提交后的状态(初始状态)
在事务未提交之前,我们都可以使用ROLLBACK进行回滚,复原。
ROLLBACK是手动回滚的指令,但是在事务遇到错误而无法继续执行的时候,会自动回滚的。
在不支持事务的存储引擎中无法进行回滚。
保存点(savepoint):
当我们在一个事务中执行了很多语句,进行了很多操作,突然发现写错了一个,那这时候该怎么办?
使用ROLLBACK回滚吗?可是ROLLBACK只能回到上次事务提交的时候(初始状态),也就是说如果使用ROLLBACK的话,之前的操作全部被推翻,只能重到再来,有种“一夜回到解放前的感觉”。
为了解决这个问题,保存点(savepoint)就诞生了。
在事务开始之后,我们可以在确认前面的操作没问题的前提下,为当前位置设置一个保存点,这样就算后面出错了也能回到当前位置,而不是最初位置。
保存点定义语句:
SAVEPOINT 自定义保存点名称
回滚到某保存点的回滚语句:
ROLLBACK TO 自定义保存点
四、事务的隔离级别
事务隔离级别的划分源于事务隔离性和服务器性能之间的矛盾,由两者间的平衡力度不同而划分。
我们的服务器可以为多个事务提供服务,当多个事务都需要访问同一数据的时候,就需要体现隔离性了,是让它们排队进行呢(串行访问,性能差),还是怎样,这就涉及到了隔离级别。
1、数据并发产生的问题
串行访问,性能差,并发访问,由涉及到隔离性,两者间如何取舍呢?
为此,我们需要先知道数据并发时所可能产生的问题都有哪些,对结果的影响程度如何。
(1)脏写( Dirty Write )
事务A修改了事务B修改而未提交的数据,此时若事务B回滚的话,事务A就会看到一个奇怪的值(和它改的不一样)
(2)脏读( Dirty Read )
脏读和脏写的情况有些类似,事务A查看了事务B修改而未提交的数据,若事务B回滚的话,事务A相当于读到一个不存在的数据,这就是脏读。
(3)不可重复读( Non-Repeatable Read )
不可重复读,顾名思义就是不能重复读取数据,因为重复读取的数据不一致,一次是一个样,另一次又是另外一个样。
强调的是在一个事务A开启的过程中,别的事务B可以更改事务A中的数据并进行修改提交,造成事务A前后查询结果不一致!!
**注意和脏读区别:**脏读是指可以访问到未提交的数据,不可重复读是指在事务A查询的时候,其他事务可以对它所查询的数据进行修改。
(4)幻读( Phantom )
事务A查询一次后,事务B增加了某些行并提交,当事务A再次查询时,发现了幻影记录(事务B增加的行)。
强调的是第二次读取比第一次的多!
2、SQL中的四种隔离级别
针对上述提到的并发产生的问题,根据严重性大小进行排序:
脏写 > 脏读 > 不可重复读 > 幻读
并发会引发上述问题,并发度越高,隔离性越低,当串行时,隔离性最高,但性能却最低。
为此,SQL标准中制定了四个隔离级别:
- READ UNCOMMITTED :读未提交, 事务A可以读到别的事务B未提交的执行结果(中间数据),因此,可能导致脏读、不可重复读、幻读 。
- READ COMMITTED :读已提交, 事务A只能读到别的事务B提交后的结果,可以避免产生脏读,但是不可重复读,幻读的问题仍然存在。
- REPEATABLE READ :可重复读, 通过一定的机制使得事务A在别的事务B修改前后读到的数据一致,即实现了多次读取,结果一致。(这个具体的机制,我们后面再慢慢聊,不着急~)
- SERIALIZABLE :可串行化 ,事务对同一数据的访问只能串行访问,只有先来的访问结束了,其他事务才可访问,这个隔离级别可以解决上述所有并发产生的问题,但是服务器的性能却极差。
因为脏写的问题是最严重的(事务修改了数据,实际上却没有修改),所以SQL中制定的四个隔离级别都解决了脏写问题,所以此处就不谈脏写了。
脏写的严重性体会:
某老板开了家网店可以销售价值100的物件,为了优惠顾客,最初价格是10,后来优惠期过了,他的管理员启动事务B想把价格改回100的,可却手抖写少了两个0,成了1,但现在事务B还没提交;此时,老板启动事务A发现显示的价格是1,因此他赶紧骂骂咧咧地来修改为100并提交,可是另一边他的管理员发现错误了,他执行ROLLBACK回滚。。
此时,若老板和管理员说:“你不用管了,我已经修改好了,就用这个价格吧”
然而此时的真实价格是1.并不是100,如果继续下去的话,那老板岂不是亏惨了??
五、MySQL中支持的四种隔离级别
MySQL中默认的隔离级别是REPEATABLE READ ,但是我们可以通过以下语句修改:
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL SERIALIZABLE;` `\#或` `SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = 'SERIALIZABLE';
使用GLOBAL或SESSION的区别:
GLOBAL针对所有事务会话有效,SESSION只针对当前事务会话有效。
两者都不影响之前或当前的事务,只会影响后续事务。
是我们可以通过以下语句修改:
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL SERIALIZABLE;` `\#或` `SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = 'SERIALIZABLE';
使用GLOBAL或SESSION的区别:
GLOBAL针对所有事务会话有效,SESSION只针对当前事务会话有效。
两者都不影响之前或当前的事务,只会影响后续事务。
|