巴黎人游戏官网或者当一个正在读取数据的进程

作者: 网络时代  发布:2019-11-07

一.事务的概述

   上一章节里,重点讲到了锁,以及锁与事务的关系。离上篇发布时间好几天了,每天利用一点空闲时间还真是要坚持。听《明朝那些事儿》中讲到"人与人最小的差距是聪明,人与人最大的差距是坚持"很经典的一句话一直记得。这篇重点围绕事务来开展。涉及的知识点包括:事务的概述,事务并发控制模型,并发产生的负面影响,事务隔离级别以及不同的表现。本章多以文字描述为主,没有多少代码量,重点是阐述不同隔离级别的不同表现,在以后的业务中,涉及到事务时,本文可以用来做个参考。

1.1 事务ACID

    事务作为一个逻辑工作单元执行一系列的操作,它包括四个属性:原子性、一致性、隔离性和持久性 (ACID) 属性, 只有这样才能成为一个事务。  

    原子性:当一个事务被当作一个单独的工作单元时,不管事务内有什么,都是一个整体。对于其数据修改,要么全都执行,要么全都不执行。  

       一致性:事务在完成时,必须使所有的数据都保持一个逻辑一致状态。   

  隔离性:并发事务所做的修改必须与其他并发事务所做的修改隔离。 事务能识别数据所处的状态,要么是另一并发事务修改它之前的状态,要么是并发事务修改它之后的状态。

  持久性:一但事务完全,它的效果是永久存于系统的。该修改即使出现系统故障也将一直保持。 SQL Server 2014和更高版本启用延迟的持久事务。

1.2 事务的操作模式有几下几种:

  自动提交事务:每条单独的语句都是一个事务。

  显式事务:每个事务均以 BEGIN TRANSACTION 语句显式开始,以 COMMIT 或 ROLLBACK 语句显式结束。

  隐式事务:在前一个事务完成时新事务隐式启动,但每个事务仍以 COMMIT 或 ROLLBACK 语句显式完成。

  批处理级事务:只能应用于多个活动结果集 (MARS),在 MARS 会话中启动的 Transact-SQL 显式或隐式事务变为批处理级事务。在sql server 2000 必须对每个 SqlCommand 对象使用独立的 SqlConnection 对象。但是 SQL Server 2005 启用了 MARS,可以共用一个SqlConnection 对象。

       本章重点讲到显式事务的隔离级别

关于数据库事务隔离级别的介绍

MSSQL锁定-1.隔离级别 Isolation level
MSSQL锁定-2.Transaction
MSSQL锁定-3.死锁与阻塞

1   概述

二. 事务并发模型

  2.1 并发访问是指:多用户同时访问一种资源被视为并发访问资源。 并发数据访问需要某些机制,以防止多个用户试图修改其他用户正在使用的资源时产生负面影响,机制就是下面讲的事务隔离级别。处于活动状态而不互相干涉的并发用户数据越多,并发性就越好。当一个正在修改数据的用户阻止了其他用户读取数据,或者当一个正在读取数据的用户阻止了其它用户修改数据时,并发性就降低了。

  2.2 并发类型

    在sqlserver里数据库系统可以采用两种方式来管理并发数据访问:乐观并发控制和悲观并发控制,在sql server 2000以前只有悲观并发。乐观并发控制是一种称为行版本控制(row versioning)的技术支持。这二种技术并发控制的区别在于:是在冲突发生前进行防止,还是在发生后采用某种方法来处理冲突。

  悲观并发控制

      在悲观并发中,sql server是获取锁来阻塞对于其它用户正在使用数据的访问。  用户操作的读与写之间是会互相阻塞的。

       乐观并发控制

    乐观并发控制默认采用行版本控制使其它用户能够看到修改操作发生以前的数据状态,旧版本数据行会保存下来。因些读取数据不会受到其它用户正对该数据进行修改操作的影响,换言之修改数据不会受到其它用户正对该数据进行读取影响。 因为读取用户访问的数据行是一个被保存过的版本。  用户读与写之间不会互相阻塞,但写与写还是会发生阻塞。

  2.3  事务并发带来的负面影响

       修改数据的用户会影响同时读取或修改相同数据的其他用户。 即这些用户可以并发访问数据。 如果数据存储系统没有并发控制,则用户可能会看到以下负面影响:

并发影响 

定义

丢失更新                                                            

       当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,会发生丢失更新问题。 每个事务都不知道其他事务的存在。   最后的更新 将覆盖由其他事务所做的更新,这将导致数据丢失。 

脏读

 当一个用户修改了数据但尚未提交修改,而另一个正在读取的用户会读到这个修改从而导致不一致的状态发生。

不可重复读

一个用户在同一个事务中分别以两个读操作间隔读取相同资源时可能会得到不同的值。

虚拟读取(幻影)

一个事务里执行两个相同的查询,但第二个查询返回的行集合是不同的,此时就会发生虚拟读取。这种情况发生在where 查询中,比如 where count(1)<10。  同一个事务中多次使用相同的条件查询,select操作返回不同数据的结果集。

事务(Transaction)是并发控制的基本单位。所谓的事务,它是一个操作序列,这些操作要么都执行,要么都不执行,它是一个不可分割的工作单位。例如,银行转账工作:从一个账号扣款并使另一个账号增款,这两个操作要么都执行,要么都不执行。所以,应该把它们看成一个事务。事务是数据库维护数据一致性的单位,在每个事务结束时,都能保持数据一致性。

--Ref

本篇文章简要对事物与锁的分析比较详细,因此就转载了。

三.事务隔离级别

  在sql server 2005及以上 支持五种隔离级别来控制“读”操作的行为,其中有三个是悲观并发模式,一个是乐观并发模式,剩下一个存在两种模式。 下面介绍隔离级别从允许的并发负作用(例如脏读或虚拟读取)的角度进行描述。

隔离级别

 定义

未提交读
READUNCOMMITTED 

 隔离事务的最低级别,未提交读不会发出共享锁,允许脏读,一个事务可能看见其他事务所做的尚未提交的更改。未提交读不会发出共享锁. 该项的作用与与SELECT表上加NOLOCK相同。

 

已提交读
READ COMMITTED

 一个事务不能读取其它事务修改但未提交的数据,避免了脏读。事务内语句运行完后便会释放共享锁,而不是等到事务提交的时候。 这是数据库引擎默认级别。

可重复读
REPEATABLE READ

 事务内查询语句运行完后不会释放共享锁,而是等到事务提交后.其它事务不能修改,删除,但可以插入新数据。
 因为不是范围锁,可能发生虚拟读取

 可序列化SERIALIZABLE

 隔离事务的最高级别,事务之间完全隔离。 阻止其它事务删除或插入任何行。 相当于SELECT上加HOLDLOCK相同, SELECT 操作使用 WHERE 子句时获取范围锁,主要为了避免虚拟读取

已提交读 快照隔离
READ COMMITTED SNAPSHOT ISOLATION level (RCSI)

当 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON 时,已提交读隔离使用行版本控制提供语句级读取一致性。 读取操作只需要 SCH-S 表级别的锁,不需要页锁或行锁。 使用行版本控制为每个语句提供一个在事务上一致的数据快照,因为该数据在语句开始时就存在。 

快照隔离
SNAPSHOT ISOLATION level
(SI)

 快照隔离级别使用行版本控制来提供事务级别的读取一致性。 读取操作不获取页锁或行锁,只获取 SCH-S 表锁。 读取其他事务修改的行时,读取操作将检索启动事务时存在的行的版本。 当 ALLOW_SNAPSHOT_ISOLATION 数据库选项设置为 ON 时,只能对数据库使用快照隔离。 默认情况下,用户数据库的此选项设置为 OFF。

  sql server主要是通过共享锁申请和释放机制的不同处理,来实现不同的事务隔离级别。不同隔离级别允许的并发副作用如下:

隔离级别 脏读 不可重复读 幻影读 并发控制模型
 未提交读 悲观
 已提交读 悲观
 已提交读快照 乐观
 可重复读 悲观
 快照 乐观
可串行化 悲观

  不同隔离级别对共享锁的不同处理方式如下:

隔离级别 是否申请共享锁 何时释放 有无范围锁
未提交读  
已提交读 当前语句做完时
可重复读 事务提交时
可序列化 事务提交时

针对上面的描述可以看出,事务的提出主要是为了解决并发情况下保持数据一致性的问题。

  • 并发的影响:
    该文章列出了并发引起的四种影响:丢失更新、脏读(未提交的依赖关系)、不可重复读(不一致的分析)、幻读
  • 并发控制类型:
    当许多人试图同时修改数据库中的数据时,必须实现一个控制系统,使一个人所做的修改不会对他人所做的修改产生负面影响。这称为并发控制。并发控制类型分为两大类:乐观并发控制和悲观并发控制

2   具体内容

四.事务隔离不同表现

* *  设置未提交读 

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

 设置提交读 

SET TRANSACTION ISOLATION LEVEL READ COMMITTED 

    设置可重复读

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ 

   4.1 未提交读和提交读与其它事务并发,的区别如下表格:

未提交读

提交读

其它事务


SELECT Model FROM Product

WHERE SID=10905

显示model 值为test


SELECT Model FROM Product 

WHERE SID=10905

显示model 值为test

begin  tran

update  product set model='test1'

where SID=10905

SET TRANSACTION ISOLATION
LEVEL READ UNCOMMITTED

SET TRANSACTION ISOLATION 

LEVEL READ COMMITTED

 这个事务将model值改为test1.

 此时修改的X锁未释放

 

SELECT Model FROM Product

WHERE SID=10905

显示model值为test1,但这并不正确,

因为其它事务还没有提交。没有获取共享锁

 

SELECT Model FROM Product

WHERE SID=10905

查询被阻塞

申请获取共享锁时失败,因为X锁未释放

 

  阻塞消失,得到的值还是test

 rollback tran

这里事务回滚了x锁释放,值还是test

   4.2  已提交读和可重复读与其它事务并发,的区别如下表格:

已提交读

可重复读 其它事务

SET TRANSACTION ISOLATION
LEVEL READ UNCOMMITTED
begin tran
SELECT Model FROM
ProductWHERE SID=10905
第一次查询显示model值为 test

SET TRANSACTION ISOLATION
LEVEL REPEATABLE READ
begin tran
SELECT Model FROM Product
WHERE SID=10905
第一次查询显示model值为 test

 

   

begin tran
update product set model='test1'
where SID=10905
将model值改为 test1

另一事务是已提交读时,这里事务修改成功
提交读共享锁查询后就释放。

另一事务是可重复读时,这里事务修改阻塞
可重复读共享锁一直保留到事务提交

SELECT Model FROM Product
WHERE SID=10905
第二次查询值显示为 test1

SELECT Model FROM Product
WHERE SID=10905
第二次查询显示值显示为 test

 

commit tran

这里就是一个事务里多次读取同一值
结果可能不一致

  commit tran  

   未完...sql server 锁与事务拨云见日(下)

事务具有以下4个基本特征。

--一、数据库事务 

并发可以定义为多个进程同时访问或修改共享数据的能力。处于活动状态而互不干涉的并发用户进程的数量越多,数据库系统的并发性就越好。当一个正在修改数据的进程阻止了其他进程读取该数据,或者当一个正在读取数据的进程阻止了其他进程修改该数据,并发性就降低了。本文用术语“读取”或者“访问”描述数据上的SELECT操作,用“写入”或“修改”描述数据上的INSERT,UPDATE以及DELETE操作。

● Atomic(原子性):事务中包含的操作被看做一个逻辑单元,这个逻辑单元中的操作要么全部成功,要么全部失败。

事务是作为单个逻辑工作单元执行的一系列操作。可以是一条SQL语句也可以是多条SQL语句。

一般地,数据库系统可以采用两种方式来管理并发数据访问,乐观并发控制和悲观并发控制。

● Consistency(一致性):只有合法的数据可以被写入数据库,否则事务应该将其回滚到最初状态。

in a multi-user application env, transactions, locking mechanisms, isolation levels and wait mode

并发控制模型

对于任何一种并发控制模式,如果两个事务试图同一时刻修改数据的话都会产生冲突。这两种模式之间的区别在于,是在冲突发生前进行防止,还是发生后采取某种方法来处理冲突。

● Isolation(隔离性):事务允许多个用户对同一个数据进行并发访问,而不破坏数据的正确性和完整性。同时,并行事务的修改必须与其他并行事务的修改相互独立。

一个支持事务(Transaction)的数据库系统,必需要具有这四种特性,否则在事务过程(Transaction processing)当中,无法保证数据的正确性。

悲观并发控制

对于悲观并发控制,该模型假定系统中存在足够多的数据修改操作,以致于事务的任何数据读取/修改操作都可能受到其他事务数据修改操作的影响,即假定冲突总是会发生的。SQL Server默认通过(lock)来保证读者和写者之间的互斥。

● Durability(持久性):事务结束后,事务处理的结果必须能够得到固化。

原子性 Atomicity: 一个操作一样不被打断 BEGIN...END. The transaction is either performed entirely or not performed at all

乐观并发控制

对于乐观并发控制,该模型假定系统中存在非常少的相互冲突的数据修改操作,以致任何单独的事务都不太可能修改其它事务正在修改的数据。乐观并发控制默认采用行版本控制来处理并发。

例如,在读取数据时我们会得到一个数据的版本version 1,当需要修改数据时,我们先检查数据的版本是不是version 1,如果是就修改数据;如果不是,就说明在当前事务的读操作和写操作之间已经有别的事务对数据进行了修改(每次修改操作都会使得数据的版本 1),SQL Server将会产生一个错误消息,由上层应用程序响应此错误。

数据库肯定是要被广大客户所共享访问的,那么在数据库操作过程中很可能出现以下几种不确定情况。

一致性Consistency: If the database was consistent before the execution of the transaction .It should remain consistent after the complete execution of that transaction.

事务处理

巴黎人游戏官网,无论是采用哪种并发控制模型,对于事务的理解是至关重要的。事务是SQL Server中任务的基本单位。典型地,它由几个读取和修改数据的SQL命令组成,但是直到COMMIT命令被执行以后,修改操作才被认为是终结了。

● 更新丢失(Lost update):两个事务都同时更新一行数据,但是第二个事务却中途失败退出,导致对数据的两个修改都失效了。这是因为系统没有执行任何的锁操作,因此并发事务并没有被隔离开来。

隔离性 Isolation: The transaction should not be interfered by any other transaction executing concurrently.

ACID属性

原子性(Atomicity) SQL Server保证事务的原子性。原子性指的是每个事务要么全部执行,要么什么都不执行。也就是说,如果一个事务提交了,它造成的所有效果都会被保留。如果中止了,其所有效果都会被撤销。

一致性(Consistency) 一致性属性确保事务不允许系统到达一个不准确的逻辑状态——数据必须总是保持逻辑上的正确。即使在发生系统故障时,约束和规则必须得到保证。(一致性一般被原子性、隔离性以及持久性所涵盖,并且概念上会产生重复)

隔离性(Isolation)
隔离性会将并发事务与其他并发事务的更新操作分隔开。当该事务正在执行时,其他事务是无法看到进行中的任务的。SQL Server会在事务之间自动实现隔离。它采用锁定数据或者行版本使得多个并发事务能够并发操作数据,以防止导致不正确结果。

隔离性意味着事务必须在不干扰其他事务的前提下独立执行。换言之,在事务执行完毕之前,其所访问的数据不能受系统其他部分的影响。

持久性(Durability) 当事务提交之后,SQL Server的持久性属性就会确保该事务的作用持续存在(即使发生系统故障)。如果在事务进行过程中发生系统故障,事务就会被完全撤销,不会在数据上遗留部分作用。如果在事务的提交确认被发送到调用的程序之后立刻发生故障,数据库会确保该事务的存在。预写式日志以及SQL Server启动恢复阶段的事务自动回滚/自动重做机制能够确保持久性。

● 脏读取(Dirty Reads):一个事务开始读取了某行数据,但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险的,因为很可能所有的操作都被回滚。

持久性 Durability: The changes made by the transaction should be permanently committed in the database.

一致性问题

事务总是全部支持ACID属性的。事务可能还会表现出一些另外的行为,称为“一致性问题”,而我并不认为它们是“问题”。它们仅仅是可能存在的行为,而用户能够决定允许哪些和阻止哪些,用户对于隔离级别的选择决定了下列这些行为中哪些是被允许的。

● 不可重复读取(Non-repeatable Reads):一个事务对同一行数据重复读取两次,但是却得到了不同的结果。例如,在两次读取的中途,有另外一个事务对该行数据进行了修改,并提交。

(另外的描述:多个事务同时进行,它们之间应该互不干扰.应该防止一个事务处理其他事务也要修改的数据时,不合理的存取和不完整的读取数据)

丢失更新

当两个事务读取相同数据并且都处理该数据(修改了它的值),然后都尝试更新原来的数据成新的值时,这种行为就会发生了。第二个事务可能完全覆盖掉第一个所完成的更新。

时间 取款事务A 取款事务B
T1 开始事务  
T2   开始事务
T3   查询账户余额为1000
T4 查询账户余额为1000  
T5   取出100,存款余额为900
T6 取出300,存款余额为700  
T7 提交事务  
T8   提交事务

最终账户余额为900,取款事务A的更新丢失了。丢失更新是这些行为中唯一一个用户可能在所有情况下都想避免的行为。

● 两次更新问题(Second lost updates problem):无法重复读取的特例。有两个并发事务同时读取同一行数据,然后其中一个对它进行修改提交,而另一个也进行了修改提交。这就会造成第一次写操作失效。

启动事务:使用 API 函数和 Transact-SQL 语句,可以按显式、自动提交或隐式的方式来启动事务。

脏读

这种行为在一个事务读取未提交数据时会发生,如果一个事务修改了数据但是尚未提交修改,而另一个正在读取数据的事务会读到这个修改从而导致一种不一致的状态发生。

时间 查询事务A 取款事务B
T1 开始事务  
T2   开始事务
T3   查询账户余额为1000
T4   取出100,存款余额为900
T5 查询账户余额为900  
T6   撤销事务,恢复为1000
T7 提交事务  

查询事务A读取到取款事务B还未提交的余额900。
默认情况下,脏读是不允许的。谨记:更新数据的事务是无法控制别的事务在它提交之前读取其数据的,这是由读取数据的事务来决定是否想要读取未必会被提交的数据。

● 虚读(Phantom Reads):事务在操作过程中进行两次查询,第二次查询的结果包含了第一次查询中未出现的数据(这里并不要求两次查询的SQL语句相同)。这是因为在两次查询过程中有另外一个事务插入数据造成的。

结束事务:您可以使用 COMMIT(成功) 或 ROLLBACK(失败) 语句,或者通过 API 函数来结束事务。

不可重复读

这种行为又被称为“不一致分析”。如果同一事务分别以两个读操作读取相同资源时,可能会得到不同的值,这就是不可重复读。

时间 查询事务A 取款事务B
T1 开始事务  
T2   开始事务
T3 查询账户余额为1000  
T4   取出100,存款余额为900
T5 查询账户余额为900  
T6   提交事务
T7 提交事务  

查询事务A两次读取余额获取到不同结果。

数据库的隔离级别

创建事务的原则:尽可能使事务保持简短很重要,当事务启动后,数据库管理系统 (DBMS) 必须在事务结束之前保留很多资源、以保证事务的正确安全执行。特别是在大量并发的系统中, 保持事务简短以减少并发 资源锁定争夺,将先得更为重要。

幻读

这种行为产生于一个数据集内的部分数据被修改时。如果事务A读取与搜索条件相匹配的若干行。事务B以插入或删除行等方式来修改事务A的结果集,然后再提交。

时间 取款记录处理事务A 取款事务B
T1 开始事务  
T2   开始事务
T3 查询到5条取款记录  
T4   查询余额为1000元
T5   取出100,存款余额为900
T6 查询到6条取款记录  
T7 提交事务  
T8   提交事务

对于取款记录处理事务A,两次查询的结果集不同。

 

事务的行为取决于隔离级别,也就是决定上述四种行为中那些是被允许的。并发控制模型决定了隔离级别是如何实现的——或者更明确的讲,决定了SQL Sever是如何确保用户所不想要的行为不发生的。

为了避免上面出现的几种情况,在标准SQL规范中,定义了4个事务隔离级别,不同的隔离级别对事务的处理不同。

           1、事务处理,禁止与用户交互,在事务开始前完成用户输入。

隔离级别

SQL Server支持五种隔离级别来控制读操作的行为。其中三个只在悲观并发模型中可用,一个只在乐观并发模型中可用。剩下的一个在两个模式下都是可用的。

巴黎人游戏官网 1

● 未授权读取(Read Uncommitted):允许脏读取,但不允许更新丢失。如果一个事务已经开始写数据,则另外一个数据则不允许同时进行写操作,但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

           2、在浏览数据时,尽量不要打开事务

未提交读

除了丢失更新以外,上面提到的其他行为都可能发生。未提交读是通过使读操作不占用任何锁来实现的,当前事务能够读取其他事务已经修改过但是尚未提交的数据。

当采用未提交读时,用户是放弃了对高一致性数据的把握而趋向于支持系统的高并发能力,使用户不会再互相锁定对方。那么,何时才应该选择未提交读呢?显然,每笔数据都须保证平衡的金融交易是不适合的。而对于某些决策支持分析来说可能会很适合(譬如,需要察看销售走势时),因为完全没有必要做到完全精确而且会带来并发性能的提升,因此是相当值得的。

● 授权读取(Read Committed):允许不可重复读取,但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。

           3、尽可能使事务保持简短。

已提交读

已提交读是数据库引擎的默认级别。SQL Server 2005支持两种已提交读的隔离级别,这种隔离级别既可以是乐观的也可以是悲观的,默认采用悲观并发控制。为了区分,悲观实现称“已提交读(锁定)”,乐观实现称为”已提交读(快照)”。

已提交读隔离级别保证了一个操作不会读到别的程序已经修改但是尚未提交的数据。如果别的事务正在更新数据并因此在数据行上持有排它锁,当前的事务就必须等待这些锁释放后才能使用这个数据(无论是读取还是修改)。同样地,事务必须至少在要被访问的数据上加上共享锁,其他事务可以读取数据但是不能修改数据。默认,共享锁在数据读取过后就被释放掉,而无需在事务的持续时间内保留。

已提交读(快照),也能保证一个操作不会读到未提交数据,但不是通过迫使其他进程等待的方式。对于已提交读(快照),每当一行数据被修改后,SQL Server就会生成该行数据前一次已提交值的一个版本(version),被修改的数据仍旧被锁定着,但是其他进程可以看到该数据在更新操作开始之前的版本。

● 可重复读取(Repeatable Read):禁止不可重复读取和脏读取,但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。

           4、考虑为只读查询使用快照隔离,以减少阻塞。

可重复读

可重复读是一种悲观的隔离级别。它在已提交读的基础上增加了新的属性:确保当事务重新访问数据或查询被再一次执行时,数据将不再发生改变。换句话说,在一个事务中执行相同的查询两次是不会看到由其他事务所造成的任何数据的改变的。然而,可重复读隔离级别还是允许幻读的出现。

在某些情况下,防止不可重复读是用户向往的一种安全措施。但是世上没有免费的午餐,这种额外的措施所带来的开销是事务中所有的共享锁必须保留到事务完成为止。

排它锁必须总是保留到事务结束为止,无论采用何种隔离级别或者并发模型,这样事务才能在需要时被回滚。如果锁提前释放了,就不太可能完成撤销操作,因为其他并发事务可能已经使用了同一数据,并且修改了它的值。
只要事务是打开的,没有其他用户可以修改被该事务所访问的数据。显然这会严重降低并发性和性能。因此,如果事务不保持简短或者编写应用程序时没有能够注意到这样潜在的锁竞争问题,将会导致大量的事务因为等待锁释放而挂起。

● 序列化(Serializable):提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

           5、灵活地使用更低的事务隔离级别。

快照

快照隔离是一种乐观隔离级别,类似于已提交读(快照),如果当前版本被锁定住时,它允许其他事务读取已提交数据的早期版本。快照隔离和已提交读(快照)的区别与(早期版本该有多早、保留多少个早期版本)这个问题相关,我们在行版本控制小节中详述。尽管快照隔离所避免的行为和可串行化所避免的是相同的,但是快照隔离并不是真正意义上的可串行化隔离级别。对于快照隔离,可能会有两个个事务同时执行,并引起一个任何序列化执行都不可能产生的结果。

巴黎人游戏官网 2

如果两个事务并行地运行,最终会交换titles表里两本书的价格。然而,不存在一种序列化执行的方式最终导致数值的交换。无论是先执行事务1然后执行事务2,还是先执行事务2再执行事务1,任何序列顺序最终将导致两本书拥有相同的价格。

本文由巴黎人游戏官网发布于网络时代,转载请注明出处:巴黎人游戏官网或者当一个正在读取数据的进程

关键词: