事务概述
事务是数据库区别于文件系统的重要特性之一，当我们有了事务就会让数据库始终保持一致性，同时我们还能通过事务机制恢复到某个时间点，这样可以保证已提交到数据库的修改不会因为系统崩溃而丢失。
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：表示不会出现的可能性。
脏写没有涉及到？因为脏写这个问题太严重了，不论是哪种隔离级别，都不允许脏写的情况发生。
不同的隔离级别有不同的现象，并有不同的锁和并发机制，隔离级别越高，数据库的并发性能就越差。
