MySQL深入理解事务（详解）

事务概述

事务是数据库区别于文件系统的重要特性之一，当我们有了事务就会让数据库始终保持一致性，同时我们还能通过事务机制恢复到某个时间点，这样可以保证已提交到数据库的修改不会因为系统崩溃而丢失。

1、基本概念

事务：一组逻辑操作单元，是数据库从一种状态变换到另一种状态。

事务处理的机制：保证所有的事务都作为一个工作单元来执行，即使出项了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都提交commit,那么这些修改就永久的保存下来；要么数据库管理系统将放弃所作的所有修改，整个事务回滚rollback到最初状态

#案例：AA用户给BB用户转账100
update account set money = money - 100 where name = 'AA';
update account set money = money + 100 where name = 'BB';

2、事务的ACID特性

• 原子性（atomicity）

原子性是指事务是一个不可分割的工作单元，要么全部提交，要么全部失败回滚。既要么转账成功，要么转账失败，是不存在中间的状态。如果无法保证原子性会怎么样？就会出项数据不一致的情形，A账户减去100元，而B账户增加100元操作失败，系统将无故丢失100元。

• 一致性（consistency）

一致性是指事务执行前后，数据从一个合法性状态变换到另外一个合法性状态。这种状态是语义上的而不是语法上的，跟具体的业务有关。

那什么是合法的数据状态呢？满足预定的约束的状态就叫做合法的状态。通俗一点，这状态是由你自己来定义的（比如满足现实世界中的约束）。满足这个状态，数据就是一致性的，不满足这个状态，数据就是不一致的！如果事务中的某个操作失败了，系统就会自动撤销当前正在执行的事务，返回到事务操作之前的状态。

举例1：A账户有200元，转账300元出去，此时A账户余额为-100元。你自然就发现了此时数据是不一致的，为什么呢？因为你定义了一个状态，余额这列必须>=0。

举例2：A账户有200元，转账50元给B账户，A账户的钱扣了，但是B账户因为各种意外，余额并没有增加。你也知道此时数据是不一致的，为什么呢？因为你定义了一个状态，要求A+B的总余额 必须不变。

• 隔离性（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';

事务1	事务2
从磁盘上将A账户余额读取到变量A中 A为200
执行操作A=A-50
将A的值写回磁盘 A为150
从磁盘中将B账户余额读取到变量B中 B为0
执行操作B=B+50
	从磁盘上将A账户余额读取到变量A中 A为150
	执行操作A=A-50
	将A的值写回磁盘 A为100
	从磁盘中将B账户余额读取到变量B中 B为0
	执行操作B=B+50
	将B值写回磁盘 B为50
将B值写回磁盘 B为50

• 持久性（durability）

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其他操作的数据库故障不应该对其他有任何影响。

持久性是通过事务日志来保证的。日志包括了重做日志和回滚日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样中的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。

总结：ACID是事务的四大特性，在这四个特性中，原子性是基础，隔离性是手段，一致性是约束条件，而持久性是我们的目的。数据库事务，其实就是数据库设计者为了方便起见，把需要保证的原子性，隔离性，一致性和持久性的一个或多个数据库操作称为一个事务。

3、数据并发问题

针对事务的隔离性和并发性，我们怎么做取舍呢？先看一下访问相同数据的事务在不保证串行执行（也就是执行完一个再执行另一个）的情况下可能会出现哪些问题：

1、脏写（Dirty Write）

对于两个事务SessionA、SessionB，如果事务SessionA修改了另一个未提交事务SessonB修改过的数据，那就意味着发生了脏写，如图所示：

发生时间编号	SessionA	SessionB
1	Begin;
2		Begin;
3		UPDATE student SET name = ‘李四’ WHERE studentno = 1;
4	UPDATE student SET name=‘张三’ WHERE studentno = 1;
5	COMMIT;
6		ROLLBACK;

SessionA和SessionB各开启了一个事务，SessionB中的事务先将studentso列为1的记录的name更新为‘李四’，然后SessionA中的事务接着又把这条studentno列为1的记录的name列更新为‘张三’。如果之后SessionB中的事务进行了回滚，那么SessionA中更新也将不复存在，这种现象就称之为脏写。这时SessionA中的事务就没有效果了，明明把数据更新了，最后也提交事务了，最后看到的数据没有变化。这里大家对事务的隔离级别比较了解的话，会发现默认隔离级别下，上面SessionA中的更新语句会处于等待状态，这里只是跟大家说明一下会出现这样现象。

2、脏读（Dirty Read）

对于两个事务SessionA、SessionB，Session A 读取了已经被Session B更新但还没有被提交的字段。之后若Session B回滚，Session A 读取的内容就是临时且无效的。如图所示：

发生时间编号	SessionA	SessionB
1	Begin;
2		Begin;
3		UPDATE student SET name = ‘张三’ WHERE studentno = 1;
4	SELECT * FROM student WHERE studentno = 1;(如果读取到列name的值为’张三’，则意味着发生了脏读)
5	COMMIT;
6		ROLLBACK;

SessionA和SeesionB各开启了一个事务，SessionB中的事务先将studentno列为1的记录的name列更新为‘张三’，然后SessionA中的事务再去查询这条studentno为1的记录，如果读取到列name的值为’张三‘，而Session B中的事务稍后进行了回滚，那么SessionA中的事务相当于读取到了一个不存在的数据，这种现象就称之为脏读。

3、不可重复读（Non-Repeatable Read）

对于两个事务SessionA、SessionB，Session A读取了一个字段，然后SessionB更新了该字段，之后Session A再次读取同一个字段，值就不同了，那就意味着发生了不可重复读。

发生时间编号	SessionA	SessionB
1	Begin;
2	SELECT * FROM student WHERE studentno = 1;(此时读到的列name的值为’王五‘)
3		UPDATE student SET name= ‘张三’ WHERE studentno = 1;
4	SELECT * FROM student WHERE studentno = 1;(如果读到列name的值为’张三‘，则意味着发生了不可重复读)
5		UPDATE student SET name = ‘李四’ WHERE studentno = 1;
6	SELECT * FROM student WHERE studentno = 1;(如果读到列name的值为’李四‘，则意味着发生了不可重复读)

我们在Session B中提交几个隐式事务（注意是隐式事务，意味着语句结束事务就提交了），这些事务都修改了studentno列为1的记录的列name的值，每次事务提交之后，如果Session A中的事务都可以查看到最新的值，这种现象就称之为不可重复读。

4、幻读（Phantom）

对于两个事务Session A、Session B，SessionA从一个表中读取了一个字段，然后SessionB在该表中插入 了一些新的行。之后，如果Session A再次读取同一个表，就会出多几行。那就意味着发生了幻读。

发生时间编号	SessionA	SessionB
1	Begin;
2	SELECT * FROM student WHERE studentno>0;(此时读取到的列name的值为’张三‘)
3		INSERT INTO student VALUES (2,‘赵六’,‘2班’)；
4	SELECT * FROM student WHERE studentno>0;(如果读取到了列name的值为’张三‘、’赵六‘的记录，则意味着发生了幻读)

SessionA中的事务先根据条件studentno >0这个条件查询表student,得到了name的值为’张三‘的记录；之后SessionB中提交了一个隐式事务，该事务向表student中插入了一条新的记录；之后SessionA中的事务再根据相同的条件studentno > 0 查询表student，得到的结果集中包含Session B中的事务新插入的那条记录，这种现象也被称之为幻读。我们把新插入的那些记录称之为幻影记录。

注意1：

有的同学会产生疑问，那如果SessionB中删除了一些符合studentno > 0的记录而不是插入新记录，那Session A之后再根据studentno > 0的条件读取的记录变少了，这种现象算不算幻读呢？这种现象不属于幻读，幻读强调的是一个事务按照某个相同条件多次读取记录时，后读取时读到了之前没有读到的记录。

注意2：

那对于先前已经读到的记录，之后又读取不到这种情况，算啥呢？这相当于对每一条记录都发生了不可重复读的现象。幻读只是重点强调了读取到了之前读取没有获取到的记录。

4、SQL中的四种隔离级别

上面介绍了几种并发事务执行过程中可能遇到的一些问题，这些问题有轻重缓急之分，我们给这些问题按照严重性来排一下序：

脏写 > 脏读 > 不可重复读 > 幻读

我们愿意舍去一部分隔离性来换取一部分性能在这里就体现在：设立一些隔离级别，隔离级别越低，并发问题发生的就越多。SQL标准中设立了4个隔离级别：

• READ UNCOMMITTED：读未提交，在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。不能避免脏读，不可重复读，幻读。
• READ COMMITTED：读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。可以避免脏读，但不可重复读，幻读问题仍然存在。
• REPEATABLE READ：可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。可以避免脏读，不可重复读，但幻读问题仍然存在。这是MySQL的默认隔离级别。
• SERIALIZABLE：可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务对该表执行插入，更新和删除操作。所有的并发问题都可以避免，但性能十分底下。能避免脏读、不可重复读和幻读。

SQL标准中规定，针对不同的隔离级别，并发事务可以发生不同严重程度的问题，具体情况如下：

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITTED	Yes	Yes	Yes	No
READ COMMITTED	No	Yes	Yes	No
REPEATABLE READ	No	No	Yes	No
SERIALIZABLE	No	No	No	Yes

Yes：表示会出现的可能性，No：表示不会出现的可能性。

脏写没有涉及到？因为脏写这个问题太严重了，不论是哪种隔离级别，都不允许脏写的情况发生。

不同的隔离级别有不同的现象，并有不同的锁和并发机制，隔离级别越高，数据库的并发性能就越差。

5、读未提交隔离性的演示

1、准备数据

 CREATE TABLE accout(id int primary key auto_increment,name varchar(15),balance decimal(10,2));
 
 
 insert into accout (id,name,balance) values (2,'张三',100),(1,'李四',0);

2、设置隔离级别

准备两个mysql （两个事务）并且都设置为read-uncommitted;

#设置隔离级别
set session transaction_isolation = 'read-uncommitted';
#查询隔离级别
select @@transaction_isolation;

3、演示脏读

事务1

begin;
update accout set balance = balance + 100 where id = 2;
select * from accout;

此时事务1还没结束，接下来使用事务2进行查询，如果事务2查询到事务1更新还没提交的数据，那么事务2查询的数据就是临时且无效的，事务2读取的数据就是脏数据（脏读）

事务2

begin;
select * from accout;

此时事务1回滚，那么事务1和事务2查询的数据应该都是回滚到之前的数据

6、读已提交和不可重复读的演示

1、读已提交设置隔离级别

set session transaction_isolation = 'read-committed';

数据准备

insert into accout (id,name,balance) values (1,'张三',100),(2,'李四',0);

事务1

 begin;
 update accout set balance = balance - 50 where id = 1;
 select * from accout;

事务2

 begin;
 select * from accout;

此时事务2查询的数据还是初始数据，那么脏读已解决。此时事务1进行提交，如果事务2查询的数据不一致，那么就出现了不可重复读的数据

事务1提交

commit;

事务2再次查询发现数据已经不一致了

如图所示，事务2在同一个事务中，两次查询的数据不一致，那么就出现了不可重复读

2、可重复读设置隔离级别

 set session transaction_isolation = 'repeatable-read';

事务1

begin;
update accout set balance = balance - 10 where id = 1
select * from accout;

可重复读解决脏读和不可重读。此时事务2查询

事务1提交，事务2在同一个事务中多次查询如结果一致，那么不可重复读解决。

此时事务2提交那么查询的应该是事务1提交之后的数据