脏读、幻读和不可重复读 + 事务隔离级别

落日映苍穹つ 2022-05-30 05:35 265阅读 0赞

[脏读、幻读和不可重复读 + 事务隔离级别][Link 1]

*  **丢失更新**：两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的；

1. **脏读**：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。  
 e.g.  
        1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务)  
        2.Mary读取自己的工资 ,发现自己的工资变为了8000，欢天喜地！  
        3.而财务发现操作有误，回滚了事务,Mary的工资又变为了1000  
          像这样,Mary记取的工资数8000是一个脏数据。

2. **不可重复读**：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。  
    e.g.  
    1.在事务1中，Mary 读取了自己的工资为1000,操作并没有完成  
    2.在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.  
    3.在事务1中，Mary 再次读取自己的工资时，工资变为了2000

解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。

3. **幻读** : 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。  
   e.g.  
   目前工资为1000的员工有10人。  
   1.事务1,读取所有工资为1000的员工。  
   2.这时事务2向employee表插入了一条员工记录，工资也为1000  
   3.事务1再次读取所有工资为1000的员工 共读取到了11条记录，  
   
 解决办法：如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题

**不可重复读的重点是修改** :  
 同样的条件, 你读取过的数据,再次读取出来发现值不一样了  
**幻读的重点在于新增或者删除**  
 同样的条件, 第 1 次和第 2 次读出来的记录数不一样

参考：[http://cupoy.iteye.com/blog/251796][http_cupoy.iteye.com_blog_251796]

[http://blog.csdn.net/d8111/archive/2008/06/29/2595635.aspx][http_blog.csdn.net_d8111_archive_2008_06_29_2595635.aspx]

[http://www.iteye.com/topic/332577][http_www.iteye.com_topic_332577]

2、在一个程序中，依据**事务的隔离级别**将会有三种情况发生。  
　　  
　　◆脏读：**一个事务会读进还没有被另一个事务提交的数据，所以你会看到一些最后被另一个事务回滚掉的数据。**  
  
　　◆不可重复读：**一个事务读进一条记录，另一个事务更改了这条记录并提交完毕，这时候第一个事务再次读这条记录时，它已经改变了**。  
  
　　◆ 幻影读：**一个事务用Where子句来检索一个表的数据，另一个事务插入一条新的记录，并且符合Where条件，这样，第一个事务用同一个where条件来检索数据后，就会多出一条记录**。

3、数据库提供了四种事务隔离级别, 不同的隔离级别采用不同的锁类开来实现.  
在四种隔离级别中, Serializable的级别最高, Read Uncommited级别最低.  
大多数数据库的默认隔离级别为: Read Commited,如Sql Server , Oracle.  
少数数据库默认的隔离级别为Repeatable Read, 如MySQL InnoDB存储引擎

SQL SERVER锁的机制  
   SQL server的所有活动都会产生锁。锁定的单元越小，就越能越能提高并发处理能力，但是管理锁的开销越大。如何找到平衡点，使并发性和性能都可接受是SQL Server的难点。  
SQL Server有如下几种琐：  
   SQL server的所有活动都会产生锁。锁定的单元越小，就越能越能提高并发处理能力，但是管理锁的开销越大。如何找到平衡点，使并发性和性能都可接受是SQL Server的难点。

**SQL Server有如下几种琐：**

**1、 共享锁**  
用于只读操作(SELECT)，锁定共享的资源。**共享锁不会阻止其他用户读，但是阻止其他的用户写和修改。**

**2、 更新锁**  
更新锁是一种意图锁，**当一个事务已经请求共享琐后并试图请求一个独占锁的时候发生更新琐。**例如当两个事务在几行数据行上都使用了共享锁，并同时试图获取独占锁以执行更新操作时，就发生了死锁：都在等待对方释放共享锁而实现独占锁。更新锁的目的是只让一个事务获得更新锁，防止这种情况的发生。

**3、 独占锁**  
一次只能有一个独占锁用在一个资源上，并且**阻止其他所有的锁**包括共享缩。写是独占锁，可以有效的防止’脏读’。

**4、 意图缩**  
在使用共享锁和独占锁之前，使用意图锁。从表的层次上查看意图锁，以判断事务能否获得共享锁和独占锁，提高了系统的性能，不需从页或者行上检查。

**5、 计划锁**  
Sch-M,Sch-S。对数据库结构改变时用Sch-M，对查询进行编译时用Sch-S。这两种锁不会阻塞任何事务锁，包括独占锁。  
**读是共享锁，写是排他锁，先读后更新的操作是更新锁，更新锁成功并且改变了数据时更新锁升级到排他锁**

l     DEFAULT 使用数据库设置的隔离级别 ( 默认 ) ，由 DBA 默认的设置来决定隔离级别 .  
l     READ\_UNCOMMITTED 会出现脏读、不可重复读、幻读 ( **隔离级别最低，并发性能高** )  
l     READ\_COMMITTED  会出现不可重复读、幻读问题（**锁定正在读取的行**）  
l     REPEATABLE\_READ 会出幻读（**锁定所读取的所有行**）  
l     SERIALIZABLE 保证所有的情况不会发生（**锁表**）

![3c3f8c8d-7216-32b0-9bb5-e8484a2ebcc9.jpg][]

ReadCommitted：  
假设A事务对正在读取数据Data放置了共享锁，那么Data不能被其它事务改写，所以当B事务对Data进行读取时总和A读取的Data数据是一致的，所以避免了脏读。由于在A没有提交之前可以对Data进行改写，那么B读取到的某个值可能会在其读取后被A更改从而导致了该值不能被重复取得；或者当B再次用相同的where字句时得到了和前一次不一样数据的结果集，也就是幻像数据。

ReadUncommitted：  
假设A事务即不发布共享锁，也不接受独占锁，那么并发的B或者其它事务可以改写A事务读取的数据，那么并发的C事务读取到的数据的状态和A的或者B的数据都可能不一致，那么。脏读、不可重复读、幻象数据都可能存在。

RepeatableRead：  
（注意MSDN原文中的第一句话：在查询中使用的所有数据上放置锁，所以不存在脏读的情况）。  
假设A事务对读取的所有数据Data放置了锁，以阻止其它事务对Data的更改，在A没有提交之前，新的并发事务读取到的数据如果存在于Data中，那么该数据的状态和A事务中的数据是一致的，从而避免了不可重复的读取。但在A事务没有结束之前，B事务可以插入新记录到Data所在的表中，那么其它事务再次用相同的where字句查询时，得到的结果数可能上一次的不一致，也就是幻像数据。

Serializable：  
 在数据表上放置了排他锁，以防止在事务完成之前由其他用户更新行或向数据集中插入行，这是最严格的锁。它防止了脏读、不可重复读取和幻象数据。

来源：[http://www.cnblogs.com/kinghuhua/archive/2011/08/17/2142902.html][http_www.cnblogs.com_kinghuhua_archive_2011_08_17_2142902.html] **（重点参考原文章）**

[Link 1]: http://uule.iteye.com/blog/1109647
[http_cupoy.iteye.com_blog_251796]: http://cupoy.iteye.com/blog/251796
[http_blog.csdn.net_d8111_archive_2008_06_29_2595635.aspx]: http://blog.csdn.net/d8111/archive/2008/06/29/2595635.aspx
[http_www.iteye.com_topic_332577]: http://www.iteye.com/topic/332577
[3c3f8c8d-7216-32b0-9bb5-e8484a2ebcc9.jpg]: /images/20220530/3277de80847f4642a0ade4a87640c3ba.png
[http_www.cnblogs.com_kinghuhua_archive_2011_08_17_2142902.html]: http://www.cnblogs.com/kinghuhua/archive/2011/08/17/2142902.html