什么是事务
事务的结束有两种，当事务中的所有操作全部执行成功时，事务提交结束。如果其中一个操作失败，将全部回滚到事务执行之前的状态。
事务的四大特性（ACID）
1. 原子性（Atomicity ）
事务是一个原子操作单元，事务中的所有操作要么都做，要么都不做。
2. 一致性（Consistency ）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
3. 隔离性（Isolation ）
即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。隔离性可以防止事务并发执行时由于交叉执行导致数据不一致的问题。
比如说，对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
4. 持久性（Durability）
持久性是指事务完成后，对数据的修改是永久性的，即使出现系统故障也不会丢失。
事务并发引发的问题
1. 脏读
也就是说一个事务读取到了其他事务还没有提交的数据，就叫做脏读。脏读的后果：如果后一个事务回滚，那么它所做的修改，统统都会被撤销。前一个事务读到的数据，就是垃圾数据。
2. 不可重复读
在同一个事务中，再次读取数据时所读取的数据，和第1次读取的数据，不一样了。就是不可重复读。
3. 幻读
一个事务中，读取到了其他事务新增的数据，仿佛出现了幻象。（幻读与不可重复读类似，不可重复读是读到了其他事务update/delete的结果，幻读是读到了其他事务insert的结果）。
4. 第一类丢失更新
撤销一个事务时，把其它事务已提交的更新数据覆盖了。这是完全没有事务隔离级别造成的。如果事务1被提交，另一个事务被撤销，那么会连同事务1所做的更新也被撤销。
5. 第二类丢失更新
| 隔离级别 | 第一类更新丢失 | 脏读 | 不可重复读 | 幻读 | 第二类更新丢失 |
| 读未提交 | × | √ | √ | √ | √ |
| 读已提交 | × | × | √ | √ | √ |
| 可重复读 | × | × | × | √ | × |
| 可串行化 | × | × | × | × | × |
通常隔离级别越高，内部工作机制越复杂，加锁的粒度越细，效率就相对较低，较松散的隔离级别通常可以支持更高的并发。
事务隔离级别
在阐述隔离级别之前先准备一些用于测试隔离级别的数据。
1 CREATE TABLE `student` ( 2 `id` bigint(20) NOT NULL COMMENT '学生编号', 3 `name` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '学生姓名', 4 `birth` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '出生年月', 5 `sex` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '学生性别', 6 PRIMARY KEY (`id`) 7 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='学生表'; 8 9 insert into `student`(`id`,`name`,`birth`,`sex`) values 10 (1,'赵雷','1990-01-01','男'), 11 (2,'钱电','1990-12-21','男'), 12 (3,'孙风','1990-05-20','男'), 13 (4,'李云','1990-08-06','男');
1. 读未提交（Read Uncommitted）
在该隔离级别，所有事务都可以看到其他事务未提交的执行结果。读取未提交的数据，也被称之为脏读。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。
演示：将事务T1设置为read uncommitted
经过上面的实验可以得出结论，T1在T2修改和插入操作前后两次读取的数据不一致，当T2未提交时，T1读到了T2未提交的数据，即称之为脏读，该实验同时也出现了幻读和不可重复读。
2. 读已提交（Read Committed）
在一个事务中，可以读取到其他事务已经提交的数据，比如事务T1的两条相同的查询语句之间，被事务T2执行修改数据并提交，那么事务T1第二次读取到了T2已提交的数据，先后两次读取的数据不一致，这种读取也就叫做不可重复读，因为两次同样的查询可能会得到不一样的结果。
演示：将事务T1设置为Read Committed
3. 可重复读（Repeatable Read）
MySQL默认的隔离级别，在一个事务中，直到事务结束前，都可以反复读取到事务最开始时读取到的数据，并一直不会发生变化，避免了脏读、不可重复读现象，但是它还是无法解决幻读问题。
简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会读取到新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
演示：将事务T1设置为Repeatable Read
经过上面的实验可以得出结论，不论是在T2对数据更新和是否提交事务的前后，T1每次读取的数据都是一致的。但是仔细地同学会发现，在可重复读的级别下，事务T2插入了一条新的数据，但是T1却并未出现幻读地情况。按照上面地不同的隔离级别会引发的问题对照表中的描述，可重复读是会出现幻读的，这又是怎么回事呢。这里需要提到一点，多版本并发控制(Multi-Version Concurrency Control, MVCC)这样一种机制（知识点，要考！！本篇不做详解），它解决了插入情况下的幻读，但是下面的修改操作依旧存在幻读问题。
从上面的实验可以发现，T1在不知道还有其他事务干扰的情况下进行修改操作，不出意外的情况下应该更新第一次读取到的4条数据，但是最后却查出了5条被更新的记录，此时即发生了幻读，将新读取（幻读）出来的一条数据也同时更新了。
4. 可串行化（Serializable）
这是最高的隔离级别，它强制事务串行执行，使之不可能相互冲突，避免了前面说的幻读现象，简单来说，它会在读取的每一行数据上都加锁，所以可能会导致大量的超时和锁竞争，一般不推荐使用。
从上面的实验可以发现，当两个事务并发操作同一份数据时，必然会有一个事务进入等待状态，直到另外的事务结束才能继续执行。