在探讨事务中的隔离之前，先回顾一下有关事务的基础概念
基本概念
数据库中的“事务处理”是什么？
这个问题的解答是我们探讨的基础，我们知道事务是数据库中哟一个单独的执行单元（Unit），它通常由高级数据库操纵语言（例如SQL）或编程语言（例如C++和Java等）编写的用户程序的执行所引起。当在数据库中更改数据成功时，在事务中更改的数据便会提交，不再改变。否则，事务就会取消或者回滚，使更改无效。
事务满足四个属性，就是常说的ACID
- 原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
- 一致性： 执行事务前后，数据保持一致；由于并发操作带来的不一致性，通常包括以下几种类型：丢失数据修改，读“脏”数据，不可重复读和幻读（也称为产生幽灵数据）。
穿插上述这几个名词的解释：
脏读（Dirty read）: 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
不可重复读（Unrepeatableread）: 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
幻读（Phantom read）: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。
不可重复度和幻读区别：
不可重复读的重点是修改，幻读的重点在于新增或者删除。
- 隔离性： 并发访问数据库时，一个用户的事物不被其他事物所干扰，各并发事务之间数据库是独立的；
SQL 标准定义了四个隔离级别:
READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
REPEATABLE-READ（可重复读）: 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化): 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
- 持久性: 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
持久化涉及到数据库的恢复问题
事务的特性（ACID）要牢记哈
有了上面的认识之后，下面来具体看看隔离性：
隔离级别的理解
上面大致说了说隔离以及隔离级别
概念是理解的结晶，实例是帮助理解的工具
下面用一行代码 来解释一下四种隔离级别：
create table num(n int) engine=InnoDB;
insert into num(n) values(1);按照时间顺序执行下面事务：
若隔离级别是 “读未提交” ，则X的值就是2。这时候事务B虽然还没有提交，但是结果已经被A看到了。因此，Y、Z也都是2。
若隔离级别是“读提交”，则X是1，Y的值是2。事务B的更新在提交后才能被A看到。所以，Z的值也是2。
若隔离级别是“可重复读”，则X、Y是1，Z是2。之所以Y还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
若隔离级别是“串行化”，则在事务B执行“将1改成2”的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看，X、Y值是1，Z的值是2。
在具体实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。
在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。
在“读提交”隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。
这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。
事务隔离的实现
这里选择“可重复读”进行叙述
之前写过一篇博文：【数据库】讨论MySQL日志系统中的更新语句的执行
里面提到了回滚日志（undo log）：它保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。
可重复度 与 MVCC密切相关：
加入有一个值1 首先被修改为2 然后被修改为3 最后被修改为4
在这个过程中：
回滚日志大致情况如下：
当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view。
如图中看到的，在视图A、B、C，D里面，这一个记录的值分别是1、2、3、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。
对于read-view A，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。
同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A、B、C对应的事务是不会冲突的。
基于上面的说明，我们来讨论一下长事务。
长事务意味着系统里面会存在很老的事务视图。 由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。
除了对回滚段的影响，长事务还占用锁资源，所以不建议使用长事务。
