事务和隔离级别

标签：

　　脏读 dirty reads：当事务读取还未被提交的数据时，就会发生这种事件。举例来说：Transaction 1修改了一行数据，然后Transaction 2在Transaction 1还未提交修改操作之前读取了被修改的行。如果Transaction 1回滚了修改操作，那么Transaction 2读取的数据就可以看作是从未存在过的。    
　　不可重复的读 non-repeatable reads：当事务两次读取同一行数据，但每次得到的数据都不一样时，就会发生这种事件。举例来说：Transaction 1读取一行数据，然后Transaction 2修改或删除该行并提交修改操作。当 Transaction 1试图重新读取该行时，它就会得到不同的数据值（如果该行被更新）或发现该行不再存在（如果该行被删除）。    
　　虚读(幻读)phantom read：指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入新的记录，当之前事务再次读取该范围记录时，会产生幻行。
事务场景是这样的：
　　对于同一个银行帐户A内有200元，甲进行提款操作100元，乙进行转帐操作100元到B帐户。如果事务没有进行隔离可能会并发如下问题：

1. 第一类丢失更新：首先甲提款时帐户内有200元，同时乙转帐也是200元，然后甲乙同时操作，甲操作成功取走100元，乙操作失败回滚，帐户内最终为200元，这样甲的操作被覆盖掉了，银行损失100元。
2. 脏读：甲取款100元未提交，乙进行转帐查到帐户内剩有100元，这是甲放弃操作回滚，乙正常操作提交，帐户内最终为0元，乙读取了甲的脏数据，客户损失100元。
3. 虚读：和脏读类似，是针对于插入操作过程中的读取问题，如丙存款100元未提交，这时银行做报表进行统计查询帐户为200元，然后丙提交了，这时银行再统计发现帐户为300元了，无法判断到底以哪个为准？大家好像觉得统计这个东西肯定是时时更新的，这种情况很正常；但是如果统计是在一个事务中的时候就不正常了，比如我们的一个统计应用需要将统计结果分别输出到电脑屏幕和远程网络某台计算机的磁盘文件中，为了提高性能和用户响应我们分成2个线程，这时先完成的和后完成的统计数据就可能不一致，我们就不知道以哪个为准了。
4. 不可重复读：甲乙同时开始都查到帐户内为200元，甲先开始取款100元提交，这时乙在准备最后更新的时候又进行了一次查询，发现结果是100元，这时乙就会很困惑，不知道该将帐户改为100还是0。和脏读的区别是，脏读是读取前一事务未提交的脏数据，不可重复读是重新读取了前一事务已提交的数据。
5. 第二类丢失更新：是不可重复读的一种特例，如上，乙不做第二次查询而是直接操作完成，帐户内最终为100元，甲的操作被覆盖掉了，银行损失100元。感觉和第一类丢失更新类似。

　　在多个事务并发做数据库操作的时候，如果没有有效的避免机制，就会出现种种问题。大体上有三种问题，归结如下：

1.丢失更新.如果两个事务都要更新数据库一个字段X，x=100

事务A             事务B
读取X＝100     
                  读取X＝100
写入x＝X+100
                  写入x＝X+200
事务结束x=200
                  事务结束x=300
最后x==300

　　这种情况事务A的更新就被覆盖掉了、丢失了。丢失更新说明事务进行数据库写操作的时候可能会出现的问题。
2.不可重复读.一个事务在自己没有更新数据库数据的情况，同一个查询操作执行两次或多次的结果应该是一致的；如果不一致，就说明为不可重复读。还是用上面的例子

事务A             事务B
读取X＝100     
                  读取X＝100
读取X＝100     
                  写入x＝X+100

读取X＝200     
事务结束x=200
                  事务结束x=200

　　这种情况事务A多次读取x的结果出现了不一致，即为不可重复读。再有一情况就是幻影事务A读的时候读出了15条记录，事务B在事务A执行的过程中删除（增加）了1条，事务A再读的时候就变成了14（16）条，这种情况就叫做幻影读。不可重复读说明了做数据库读操作的时候可能会出现的问题。
3.脏读（未提交读）防止一个事务读到另一个事务还没有提交的记录。如：

事务A             事务B
                  读取X＝100
                  写入x＝X+100
读取X＝200     
                  事务回滚x=100
读取X＝100     
事务结束x=100

　　x锁(排他锁):被加锁的对象只能被持有锁的事务读取和修改，其他事务无法在该对象上加其他锁，也不能读取和修改该对象.s锁(共享锁）：被加锁的对象可以被持锁事务读取，但是不能被修改，其他事务也可以在上面再加s锁。
封锁协议

　　三级封锁协议： 在运用X锁和S锁对数据对象加锁时，还需要约定一些规则 ，例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。

1. 一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。一级封锁协议可以防止丢失修改，并保证事务T是可恢复的。使用一级封锁协议可以解决丢失修改问题。在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，它不能保证可重复读和不读“脏”数据。
2. 二级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后方可释放S锁。二级封锁协议除防止了丢失修改，还可以进一步防止读“脏”数据。但在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。
3. 三级封锁协议 ：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。

　　三级协议的主要区别在于什么操作需要申请封锁，以及何时释放。

数据库锁的粒度

　　所谓粒度，即细化的程度。锁的粒度越大，则并发性越低且开销大；锁的粒度越小，则并发性高且开销小。锁的粒度主要有以下几种类型：

1. 行锁，行锁是粒度中最小的资源。行锁就是指事务在操作数据的过程中，锁定一行或多行的据，其他事务不能同时处理这些行的数据。行级锁占用的数据资源最小，所以在事务的处理过程中，允许其它事务操作同一表的其他数据。
2. 页锁，一次锁定一页。25个行锁可升级为一个页锁。
3. 表锁，锁定整个表。当整个数据表被锁定后，其他事务就不能够使用此表中的其他数据。使用表锁可以使事务处理的数据量大，并且使用较少的系统资源。但是在使用表锁时，会延迟其他事务的等待时间，降低系统并发性。
4. 数据库锁，防止任何事务和用户对此数据库进行访问。可控制整个数据库的操作。用锁效率会降低，可通过使用表锁来减少锁的使用从而保证效率。

悲观锁和乐观锁
　　悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
　　乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
　　两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

事务的隔离级别

　　SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

• Read Uncommitted（读取未提交内容）。在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
• Read Committed（读取提交内容）。这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
• Repeatable Read（可重读）。这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
• Serializable（可串行化）。这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

　　  这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
　　在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：
　　下面，将利用MySQL的客户端程序，分别测试几种隔离级别。测试数据库为test，表为tx；表结构：id  int；num int.两个命令行客户端分别为A，B；不断改变A的隔离级别，在B端修改数据。
1.将A的隔离级别设置为read uncommitted(未提交读)
　　在B未更新数据之前：客户端A：
　　B更新数据客户端B：
　　客户端A：
　　经过上面的实验可以得出结论，事务B更新了一条记录，但是没有提交，此时事务A可以查询出未提交记录。造成脏读现象。未提交读是最低的隔离级别。
2.将客户端A的事务隔离级别设置为read committed(已提交读)
　　在B未更新数据之前。客户端A：
　　B更新数据。客户端B：
　　客户端A：
　　经过上面的实验可以得出结论，已提交读隔离级别解决了脏读的问题，但是出现了不可重复读的问题，即事务A在两次查询的数据不一致，因为在两次查询之间事务B更新了一条数据。已提交读只允许读取已提交的记录，但不要求可重复读。
3.将A的隔离级别设置为repeatable read(可重复读)
　　在B未更新数据之前.客户端A：

　　B更新数据.客户端B：
　　客户端A：
　　B插入数据.客户端B：
　　客户端A：

　　由以上的实验可以得出结论，可重复读隔离级别只允许读取已提交记录，而且在一个事务两次读取一个记录期间，其他事务部的更新该记录。但该事务不要求与其他事务可串行化。例如，当一个事务可以找到由一个已提交事务更新的记录，但是可能产生幻读问题(注意是可能，因为数据库对隔离级别的实现有所差别)。像以上的实验，就没有出现数据幻读的问题。
4.将A的隔离级别设置为 可串行化 (Serializable)
　　A端打开事务，B端插入一条记录.事务A端：

　　事务B端：
　　因为此时事务A的隔离级别设置为serializable，开始事务后，并没有提交，所以事务B只能等待。
　　事务A提交事务。事务A端：

　　事务B端

　　serializable完全锁定字段，若一个事务来查询同一份数据就必须等待，直到前一个事务完成并解除锁定为止 。是完整的隔离级别，会锁定对应的数据表格，因而会有效率的问题。

事务和隔离级别

标签：

原文地址：http://www.cnblogs.com/wxgblogs/p/5745996.html