原文地址：https://www.jianshu.com/p/4e3edbedb9a8
===========================================================================================
隔离级别 脏读（Dirty Read） 不可重复读（NonRepeatable Read） 幻读（Phantom Read）
===========================================================================================
未提交读（Read uncommitted） 可能 可能 可能
已提交读（Read committed） 不可能 可能 可能
可重复读（Repeatable read） 不可能 不可能 可能
可串行化（Serializable ） 不可能 不可能 不可能
===========================================================================================
·未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
·提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
·可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
·串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
首先创建一个表account。创建表的过程略过（由于InnoDB存储引擎支持事务，所以将表的存储引擎设置为InnoDB）。表的结构如下：
表结构
然后往表中插入两条数据，插入后结果如下：
数据
为了说明问题，我们打开两个控制台分别进行登录来模拟两个用户（暂且成为用户A和用户B吧），并设置当前MySQL会话的事务隔离级别。
一. read uncommitted（读取未提交数据）
具体用户A的操作如下：
- set session transaction isolation level read uncommitted；
- start transaction;
- select * from account;
结果如下：
数据
用户B的操作如下：
- set session transaction isolation level read uncommitted；
- start transaction;
- update account set account=account+200 where id = 1;
随后我们在A用户中查询数据，结果如下：
uncommittedA数据
结论一：
我们将事务隔离级别设置为read uncommitted，即便是事务没有commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。
那么这么做有什么问题吗？
那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据，这还是比较麻烦的，我们叫脏读。我不知道这个名字是怎么起的，为了增强大家的印象，可以这么想，这个事务好轻浮啊，饥渴到连别人没提交的东西都等不及，真脏，呸！
实际上我们的数据改变了吗？
答案是否定的，因为只有事务commit后才会更新到数据库。
二. read committed（可以读取其他事务提交的数据）---大多数数据库默认的隔离级别
同样的办法，我们将用户B所在的会话当前事务隔离级别设置为read commited。
在用户A所在的会话中我们执行下面操作：
update account set account=account-200 where id=1;
read committed
我们将id=1的用户account减200。然后查询，发现id=1的用户account变为800。
在B用户所在的会话中查询：
select * from account；
结果如下：
read committedB
我们会发现数据并没有变，还是1000。
接着在会话A中我们将事务提交：
commit;
在会话B中查询结果如下：
read committedB1
结论二：
当我们将当前会话的隔离级别设置为read committed的时候，当前会话只能读取到其他事务提交的数据，未提交的数据读不到。
那么这么做有什么问题吗？
那就是我们在会话B同一个事务中，读取到两次不同的结果。这就造成了不可重复读，就是两次读取的结果不同。这种现象叫不可重复读。
三. repeatable read（可重读）---MySQL默认的隔离级别
现在有个需求，就是老板说在同一个事务中查询结果必须保持一致，如果你是数据库，你会怎么做？数据库是这么做的。
在会话B中我们当前事务隔离级别为repeatable read。具体操作如下：
- set session transaction isolation level repeatable read;
- start transaction;
接着在会话B中查询数据：
repeatablereadB1
我们在A用户所在会话中为表account添加一条数据：
- insert into account(id,account) value(3,1000);
- commit;
然后我们查询看数据插入是否成功：
repeatable readA
回到B用户所在的会话，我们查询结果：
repeatablereadB2
用户B在他所在的会话中想插入一条新数据id=3，value=1000。来我们操作下：
readpeatablereadB3
什么？竟然插不进去，说我数据重复？
用户B当然不服啊，因为查询到数据只有两条啊，为什么插入id=3说我数据重复了呢？
我再看一遍，莫非我眼花了？
repeatablereadB2
试想一下，在实际中用户A和用户B肯定是相互隔离的，彼此不知道操作什么。用户B碰到这种现象，肯定会炸毛的啊，明明不存在的数据，插入却说主键id=3数据重复了。
结论三：
当我们将当前会话的隔离级别设置为repeatable read的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。
有什么问题吗？
管他呢，老板的要求满足了。要一个事务中读取的数据一致（可重复读）。我只能这么做啊，打肿脸装胖子。数据已经发生改变，但是我还是要保持一致。但是，出现了用户B面对的问题，这种现象叫幻读（记得当时就在这个地方纠结好久，到底什么是幻读啊）。
四. serializable（串行化）
同样，我们将用户B所在的会话的事务隔离级别设置为serializable并开启事务。
- set session transaction isolation level serializable;
- start transaction;
在用户B所在的会话中我们执行下面操作：
select * from account;
结果如下：
serializableA
那我们这个时候在用户A所在的会话中写数据呢？
readcommittedA1
我们发现用户A所在的会话陷入等待，如果超时（这个时间可以进行配置），会出现Lock wait time out提示：
readcommittedA2
如果在等待期间我们用户B所在的会话事务提交，那么用户A所在的事务的写操作将提示操作成功。