MySQL对事务的隔离级别共分为四个级别，分别是：
1. READ UNCOMMITTED 读未提交
2. READ COMMITTED 读提交
3. REPEATABLE 可重读
4. SERIALIABLE 可串读
MySQL默认工作在级别三下。我们知道事务隔离是为了避免并发操作相互影响而导数据的不一致性。所以为了保证数据的一致性，就引入了事务隔离的功能。以上四个级别的对数据的一致性保护是逐步提高的。级别4对事务的隔离效果最好，但是性能最差，一般不再生产环境中使用。
下面通过实例来检验不同级别下MySQL性能收到的影响。我的实验环境是：Redhat5.8+MySQL5.5首先我们这里启用两个session：
1、验证级别一的特性我们在session A上进行的操作为：
%E7%BA%A7%E5%88%AB1_B.JPG (20.06 KB, 下载次数: 7)
2015-3-27 09:32 上传
在session B上的操作同session A，这里不再附上截图。
接下来我们就通过一系列的实验来观察READ-UNCOMMITTED到底是什么，它到底有什么特性，对我们的操作到底有什么影响。首先，我们可以看到表中的初始数据如下：
%E7%BA%A7%E5%88%AB1_C.JPG (42.66 KB, 下载次数: 5)
2015-3-27 09:32 上传
接下来我们在sessionA上更改其中的一条记录，更改结果如下：
%E7%BA%A7%E5%88%AB1_D.JPG (56.84 KB, 下载次数: 5)
2015-3-27 09:32 上传
注意：我们在上面启用了事务，但是我们在这里并没有进行commit操作。
接下来我们在sessionB中对刚才改过的表进行select查询，查询结果如下：
%E7%BA%A7%E5%88%AB1_E.JPG (36.3 KB, 下载次数: 4)
2015-3-27 09:32 上传
我们可以清楚的看到，虽然我们并没有对session A的结果进行commit，但是结果确实已经改变。因此在这种级别下，没有提交的操作会对数据的一致性有影响。因此，如果我们此时在session A上对上述操作进行回滚，我们会发现此时session B上的结果又回到原来最初的结果，这样就造成了数据的不一致性，这也称为数据的幻读现象，看起来是很诡异的事情。因此在某些场景下，我们应该避免这种现象的产生。但是这种级别也不是没有它的用武之地，比如当我们有大量数据需要写入，而读操作很少的时候，就适合用这种模式。
可以看到session A回滚后，session B中的数据又变成最初的样子，这也称为幻读：
%E7%BA%A7%E5%88%AB1_F.JPG (38.31 KB, 下载次数: 7)
2015-3-27 09:32 上传2、验证级别READ COMMITTED特性 首先把session A和session B的隔离级别都改为READ-COMMITTED，并且全部都开启事务，操作如下：
%E7%BA%A7%E5%88%AB2_A.JPG (19.57 KB, 下载次数: 6)
2015-3-27 09:32 上传
接下来我们查看tutors表的初始状态信息：
%E7%BA%A7%E5%88%AB2_B.JPG (38.26 KB, 下载次数: 5)
2015-3-27 09:32 上传
然后我们依然是对数据进行更新操作，更新之后仍然没有commit。我们可以看到在sessionA中，结果已经发生改变：
%E7%BA%A7%E5%88%AB2_C.JPG (53.19 KB, 下载次数: 7)
2015-3-27 09:32 上传
此时我们在session B中查看，发现结果依然维持不变：
%E7%BA%A7%E5%88%AB2_D.JPG (38.18 KB, 下载次数: 7)
2015-3-27 09:32 上传
但是，如果我们此时在session A中进行commit操作，我们就会发现，sessionB此时查询就会发生改变，这样也造成了数据的前后不一致性，也是数据的幻读：
%E7%BA%A7%E5%88%AB2_E.JPG (35.75 KB, 下载次数: 2)
2015-3-27 09:32 上传
3、数据的可重读 数据的可重读，也叫作REPEATABLE-READ，这是MySQL默认采用的事务隔离级别，有其优势，但是仍然没有从根本上解决数据的一致性问题。首先，还是让我们来测试一下，在这种级别下MySQL到底是如何工作的，又有哪些特性，我们又该怎样去操作。
我们先把REPEATABLE-READ的环境设置好，具体的操作方法如下：
%E7%BA%A7%E5%88%AB3_A.JPG (18.08 KB, 下载次数: 4)
2015-3-27 09:32 上传
然后我们在查看其初始数据，其结果如下：
%E7%BA%A7%E5%88%AB3_B.JPG (39.64 KB, 下载次数: 6)
2015-3-27 09:32 上传
我们在session A中修改数据，并进行commit，修改后的结果如下：
%E7%BA%A7%E5%88%AB3_C.JPG (39.87 KB, 下载次数: 5)
2015-3-27 09:32 上传
然后我们在session B中进行查看发现结果仍然没有任何改变：
%E7%BA%A7%E5%88%AB3_D.JPG (39.03 KB, 下载次数: 5)
2015-3-27 09:32 上传
这就是可重读的特性，只要本次会话不提交，尽管对方修改，但是结果仍然不变，只有在session B中也进行commit操作，所作的修改才会在sessionB中生效。
4、seriabliable
这个级别是事务隔离安全性最好的，但是也是性能最差的，因为这个级别所有的操作都是串行进行的。一个操作没有提交，另一个受到影响的操作会处于阻塞状态。
为了验证这种效果，我们先把环境设置好，具体为在session A和session B同时设置如下：
%E7%BA%A7%E5%88%AB4_A.JPG (18.93 KB, 下载次数: 7)
2015-3-27 09:32 上传
在session A 中对其任意字段进行修改，并且没有进行commit操作。此时挥发现sessionB中的查询操作会一直处于阻塞状态：
%E7%BA%A7%E5%88%AB4_B.JPG (5.57 KB, 下载次数: 4)
2015-3-27 09:32 上传这就设串行化隔离的效果，也是为什么串行化隔离并发能力差的原因。
实验测试用的数据我已经上传。
