第13章 事务基础知识
1. 数据库事务概述
事务是数据库区别于文件系统的重要特性之一,当我们有了事务就会让数据库始终保持一致性
,同时我们还能通
过事务的机制恢复到某个时间点
,这样可以保证已提交到数据屏的修改不会因为系统崩溃而丢失。
1.1 存储引擎支持情况
1.2基本概念
**事务:**一组逻辑操作单元(DML操作),使数据从一种状态变换到另一种状态。
**事务处理的原则:**保证所有事务都作为一个工作单元
来执行,即使出现了故障,都不能改变这种执行方式。当在一个事务中执行多个操作时,要么所有的事务都被提交(commit
),那么这些修改就永久
地保存下来;要么数据库管理系统将放弃
所作的所有修改
,整个事务回滚(rollback
)到最初状态。
1.3事务的ACID特性
- 原子性(atomicity):
原子性是指事务是一个不可分割的工作单位,要么全部提交,要么全部失败回滚。
即要么转账成功,要么转账失败,是不存在中间的状态。如果无法保证原子性会怎么样?就会出现数据不一致的情形,A账户减去100元,而B账户增加100元操作失败,系统将无故丢失100元。
- 一致性(consistency):
一致性是指事务执行前后,数据从一个合法性状态
变换到另外一个合法性状态
。这种状态是语义上
的而不是语法上的,跟具体的业务有关。
(国内很多网站上对一致性的闸述有误,具体你可以参考wikipedia对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
元,分别在两个事务中执行。如果无法保证隔离性,会出现下面的情形:
UPDATE accounts SET money = money - 50 WHERE NAME = 'AA';
UPDATE accounts SET money = money + 50 WHERE NAME = 'BB';
- 持久性(durability):
持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的
,接下来的其他操作和数据库故障不应该对其有任何影响。
持久性是通过事务日志
来保证的。日志包括了重做日志
和回滚日志
。当我们通过事务对数据进行修改的时候,首先会将数据库的变化信息记录到重做日志中,然后再对数据库中对应的行进行修改。这样做的好处是,即使数据库系统崩溃,数据库重启后也能找到没有更新到数据库系统中的重做日志,重新执行,从而使事务具有持久性。
1.4事务的状态
- 活动的(active)
事务对应的数据库操作正在执行过程中时,我们就说该事务处在活动的
状态。
- 部分提交的(partially committed)
当事务中的最后一个操作执行完成,但由于操作都在内存中执行,所造成的影响并没有刷新到磁盘
时,我们就说该事务处在部分提交的
状态。
- 失败的(failed)
当事务处在活动的
或者部分提交的
状态时,可能遇到了某些错误(数据库自身的错误、操作系统错误或者直接断电等)而无法继续执行,或者人为的停止当前事务的执行,我们就说该事务处在失败的
状态。
- 中止的(aborted)
如果事务执行了一部分而变为失败的
状态,那么就需要把已经修改的事务中的操作还原到事务执行前的状态。换句话说,就是要撤销失败事务对当前数据库造成的影响。我们把这个撤销的过程称之为回滚
。当回滚
操作执行完毕时,也就是数据库恢复到了执行事务之前的状态,我们就说该事务处在了中止的
状态。
- 提交的(committed)
当一个处在部分提交的
状态的事务将修改过的数据都同步到磁盘
上之后,我们就可以说该事务处在了提交的
状态。
图中可见,只有当事务处于提交的
或者中止的
状态时,一个事务的生命周期才算是结束了。对于已经提交的事务
来说,该事务对数据库所做的修改将永久生效,对于处于中止状态的事务,该事务对数据库所做的所有修改都会
被回滚到没执行该事务之前的状态。
2.如何使用事务
2.1显式事务
步骤1: START TRANSACTION
或者BEGIN
,作用是显式开启一个事务。
mysql> BEGIN;
#或者
mysql> START TRANSACTION;
START TRANSACTION
语句相较于BEGIN
特别之处在于,后边能跟随几个修饰符
:
①READ ONLY
:标识当前事务是一个只读事务
,也就是属于该事务的数据库操作只能读取数据,而不能修改数据。
补充:只读事务中只是不允许修改那些其他事务也能访问到的表中的数据,对于临时表来说(我们使用
CREATE TMEPORARY TABLE创建的表),由于它们只能在当前会话中可见,所以只读事务其实也是可以对临时表进行增、删、改操作的。(特殊的情况)
②READ WRITE
:标识当前事务是一个读写事务
,也就是属于该事务的数据库操作既可以读取数据,也可以修改数据。(默认的情况)
③WITH CONSISTENT SNAPSHOT
:启动一致性读。
第一和第二只能选一个,因为只读和读写已经冲突了重复了。
**步骤2:**一系列事务中的操作(主要是DML,不含DDL)
**步骤3:**提交事务 或 中止事务(即回滚事务)
# 提交事务。当提交事务后,对数据库的修改是永久性的。
mysql> COMMIT;
# 回滚事务。即撤销正在进行的所有没有提交的修改
mysql> ROLLBACK;
# 将事务回滚到某个保存点。
mysql> ROLLBACK TO [SAVEPOINT]
其中关于SAVEPOINT相关操作有:
# 在事务中创建保存点,方便后续针对保存点进行回滚。一个事物中可以存在多个保存点。
SAVEPOINT 保存点名称;
# 删除某个保存点
RELEASE SAVEPOINT 保存点名称;
2.2 隐式事务
- 显式的的使用
START TRANSACTION
或者BEGIN
语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能。 - 把系统变量
autocommit
的值设置为OFF
2.3 隐式提交数据的情况
- 数据定义语言(Data definition language,缩写为:DDL)
- 隐式使用或修改mysql数据库中的表
当我们使用ALTER USER
、CREATE USER
、DROP USER
、GRANT
、RENAME USER
、REVOKE
、SET PASSWORD
等语句时也会隐式的提交前边语句所属于的事务。
- 事务控制或关于锁定的语句
- 当我们在一个事务还没提交或者回滚时就又使用
START TRANSACTION
或者BEGIN
语句开启了另一个事务时,会隐式的提交
上一个事务。 - 当前的
autocommit
系统变量的值为OFF
,我们手动把它调为ON
时,也会隐式的提交
前边语句所属的事务。 - 使用
LOCK TABLES
、UNLOCK TABLES
等关于锁定的语句也会隐式的提交
前边语句所属的事务。
- 当我们在一个事务还没提交或者回滚时就又使用
2.4案例分析
#SET autocommit = TRUE;
#举例1: commit 和 rollback
USE atguigudb2;
#情况1:
CREATE TABLE user3(NAME VARCHAR(15) PRIMARY KEY);
SELECT * FROM user3;
BEGIN;
INSERT INTO user3 VALUES('张三'); #此时不会自动提交数据
COMMIT;
BEGIN; #开启一个新的事务
INSERT INTO user3 VALUES('李四'); #此时不会自动提交数据
INSERT INTO user3 VALUES('李四'); #受主键的影响,不能添加成功
ROLLBACK;
SELECT * FROM user3;
#情况2:
TRUNCATE TABLE user3; #DDL操作会自动提交数据,不受autocommit变量的影响。
SELECT * FROM user3;
BEGIN;
INSERT INTO user3 VALUES('张三'); #此时不会自动提交数据
COMMIT;
INSERT INTO user3 VALUES('李四');# 默认情况下(即autocommit为true),DML操作也会自动提交数据。
INSERT INTO user3 VALUES('李四'); #事务的失败的状态
ROLLBACK;
SELECT * FROM user3;
#情况3:
TRUNCATE TABLE user3;
SELECT * FROM user3;
SELECT @@completion_type;
SET @@completion_type = 1;
BEGIN;
INSERT INTO user3 VALUES('张三');
COMMIT;
SELECT * FROM user3;
INSERT INTO user3 VALUES('李四');
INSERT INTO user3 VALUES('李四');
ROLLBACK;
SELECT * FROM user3;
#举例2:体会INNODB 和 MyISAM
CREATE TABLE test1(i INT) ENGINE = INNODB;
CREATE TABLE test2(i INT) ENGINE = MYISAM;
#针对于innodb表
BEGIN
INSERT INTO test1 VALUES (1);
ROLLBACK;
SELECT * FROM test1;
#针对于myisam表:不支持事务
BEGIN
INSERT INTO test2 VALUES (1);
ROLLBACK;
SELECT * FROM test2;
#举例3:体会savepoint
CREATE TABLE user3(NAME VARCHAR(15),balance DECIMAL(10,2));
BEGIN
INSERT INTO user3(NAME,balance) VALUES('张三',1000);
COMMIT;
SELECT * FROM user3;
BEGIN;
UPDATE user3 SET balance = balance - 100 WHERE NAME = '张三';
UPDATE user3 SET balance = balance - 100 WHERE NAME = '张三';
SAVEPOINT s1;#设置保存点
UPDATE user3 SET balance = balance + 1 WHERE NAME = '张三';
ROLLBACK TO s1; #回滚到保存点
SELECT * FROM user3;
ROLLBACK; #回滚操作
SELECT * FROM user3;
2.5 使用举例2:测试不支持事务的engine
3.事务隔离级别
MySQL是一个客户端/服务器
架构的软件,对于同一个服务器来说,可以有若干个客户端与之连接,每
个客户端与服务器连接上之后,就可以称为一个会话( Session
)。每个客户端都可以在自己的会话中
向服务器发出请求语句,一个请求语句可能是某个事务的一部分,也就是对于服务器来说可能同时处理
多个事务。事务有隔离性
的特性,理论上在某个事务 对某个数据进行访问
时,其他事务应该进行 排 队
,当该事务提交之后,其他事务才可以继续访问这个数据。但是这样对 性能影响太大
,我们既想保持
事务的隔离性,又想让服务器在处理访问同一数据的多个事务时 性能尽量高些
,那就看二者如何权衡取
舍了。
3.1 数据准备
3.2数据并发问题
1. 脏写(Dirty Write
)
对于两个事务 Session A、Session B,如果事务Session A修改了
另一个未提交
事务Session B修改过
的数据,那就意味着发生了脏写
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-97Dw7AvC-1651564377400)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031124086.png)]
2. 脏读(Dirty Read
)
对于两个事务 Session A、Session B,Session A读取
了已经被 Session B更新
但还没有被提交
的字段。之后若 Session B回滚
,Session A读取
的内容就是临时且无效
的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wBdVOZwb-1651564377401)(https://cdn.jsdelivr.net/gh/aoshihuankong/cloudimg@master/img/202204031124136.png)]
3. 不可重复读(Non-Repeatable Read
)
对于两个事务Session A、Session B,Session A读取
了一个字段,然后 Session B更新
了该字段。 之后Session A再次读取
同一个字段,值就不同
了。那就意味着发生了不可重复读。
4. 幻读(Phantom
)
对于两个事务Session A、Session B, Session A 从一个表中读取
了一个字段, 然后 Session B 在该表中插入
了一些新的行。 之后, 如果 Session A再次读取
同一个表, 就会多出几行。那就意味着发生了幻读。
注意1:
有的同学会有疑问,那如果Session B中剔除了
一些符合studentno > 0
的记录而不是插入新记录,那么Session A之后再根据studentno > 0
的条件读取的记录变少了
,这种现象算不算幻读
呢?这种现象不属于幻读
,幻读强调的是一个事物按照某个相同条件多次读取
记录时,后读取时读到了之前没有读到的记录
。
注意2:
那对于先前已经读到的记录,之后又读取不到这种情况,算啥呢?这相当于对每一条记录都发生了不可重复读
的现象。幻读只是重点强调了读取到之前读取没有获取到的记录。
3.3SQL中的四种隔离级别
上面介绍了几种并发事务执行过程中可能遇到的一些问题,这些问题有轻重缓急之分,我们给这些问题
按照严重性来排一下序:
脏写 > 脏读 > 不可重复读 > 幻读
SQL标准
中设立了4个隔离级别
:
READ UNCOMMITTED
:读未提交,在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读。READ COMMITTED
:读已提交,它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。可以避免脏读,但不可重复读、幻读问题仍然存在。REPEATABLE READ
:可重复读,事务A在读到一条数据之后,此时事务B对该数据进行了修改并提交,那么事务A再读该数据,读到的还是原来的内容。可以避免脏读、不可重复读,但幻读问题仍然存在。这是MySQL的默认隔离级别
。SERIALIZABLE
:可串行化,确保事务可以从一个表中读取相同的行。在这个事务持续期间,禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免,但性能十分低下。能避免脏读、不可重复读和幻读。
3.4MySQL支持的四种隔离级别
不同的数据库厂商对SQL标准中规定的四种隔离级别支持不一样。比如,oracle
就只支持READ COMMITTED(默 认隔离级别)
和SERIALIZABLE隔离级别
。MySQL虽然支持4种隔离级别,但与SQL标准中所规定的各级隔离级别
允许发生的问题却有些出入,MySQL在REPEATABLEREAD隔离级别下,是可以禁止幻读问题的发生的,禁止幻读
的原因我们在第16章讲解。
3.5 如何设置事务的隔离级别
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL 隔离级别;
#其中,隔离级别格式:
> READ UNCOMMITTED
> READ COMMITTED
> REPEATABLE READ
> SERIALIZABLE
或者:
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';
则:
- 当前已经存在的会话无效
- 只对执行完该语句之后产生的会话起作用
使用 SESSION 关键字(在会话范围影响):
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
#或
SET SESSION TRANSACTION_ISOLATION = 'SERIALIZABLE';
则:
- 对当前会话的所有后续的事务有效
- 如果在事务之间执行,则对后续的事务有效
- 该语句可以在已经开启的事务中间执行,但不会影响当前正在执行的事务
小结:
数据库规定了多种事务隔离级别,不同隔离级别对应不同的干扰程度,隔离级别越高,数据一致性
就越好,但并发性越弱。
事务的常见分类
从事务理论的角度来看,可以把事务分为以下几种类型:
- 扁平事务(Flat Transactions)
- 带有保存点的扁平事务(Flat Transactions with Savepoints)
- 链事务(Chained Transactions)
- 嵌套事务(Nested Transactions)
- 分布式事务(Distributed Transactions)