sql数据库中事务的并发控制问题 克服两阶段封锁协议的问题是采用变体严格两阶段封锁协议或者强两阶段

严格两阶段封锁协议不仅要求封锁是两阶段，还要求事务持有的所有排他锁必须在事务提交后方可释放。这个要求保证未提交事务所写的任何数据在该事务提交之前均已排他方式加锁，防止了其他事务读这些数据。

强两阶段封锁协议。它要求事务提交之前不释放任何锁。在该条件下，事务可以按其提交的顺序串行化。

为了有效地组织、管理数据，提高数据库的逻辑独立性和物理独立性，人们为数据库设计了一个严谨的体系结构，数据库领域公认的标准结构是三级模式结构，它包括外模式、模式和内模式。

美国家标准协会(American N ational Standard Instit ut e，ANSI)的数据库管理系统研究小组于1 9 78年提出了标准化的建议，将数据库结构分为3级：面向用户或应用程序员的用户级、面向建立和维护数据库人员的概念级、面向系统程序员的物理级。

用户级对应外模式，概念级对应模式，物理级对应内模式，使不同级别的用户对数据库形成不同的视图。所谓视图，就是指观察、认识和理解数据的范围、角度和方法，是数据库在用户“眼中"的反映，很显然，不同层次(级别)用户所“看到’’的数据库是不相同的。

1模式．

模式又称概念模式或逻辑模式，对应于概念级。它是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(Data Description Language，DDL)来描述、定义的，体现、反映了数据库系统的整体观。

2．外模式

外模式又称子模式，对应于用户级。它是某个或某几个用户所看到的数据库的数据视图，是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集，包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式)，也可以利用数据 *** 纵语言(Data Manipulation Lang uage，DML)对这些数据记录进行。外模式反映了数据库的用户观。

3．内模式

内模式又称存储模式，对应于物理级，它是数据库中全体数据的内部表示或底层描述，是数据库最低一级的逻辑描述，它描述了数据在存储介质上的存储方式翱物理结构，对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义，它是数据库的存储观。

在一个数据库系统中，只有唯一的数据库， 因而作为定义 、描述数据库存储结构的内模式和定义、描述数据库逻辑结构的模式，也是惟一的，但建立在数据库系统之上的应用则是非常广泛、多样的，所以对应的外模式不是惟一的，也不可能是惟一的。

4．三级模式间的映射 数据库的三级模式是数据库在三个级别 (层次)上的抽象，使用户能够逻辑地、抽象地处理数据而不必关心数据在计算机中的物理表示和存储。实际上 ，对于一个数据库系统而言一有物理级数据库是客观存在的，它是进行数据库 *** 作的基础，概念级数据库中不过是物理数据库的一种逻辑的、抽象的描述(即模式)，用户级数据库则是用户与数据库的接口，它是概念级数据库的一个子集(外模式)。

用户应用程序根据外模式进行数据 *** 作，通过外模式一模式映射，定义和建立某个外模式与模式间的对应关系，将外模式与模式联系起来，当模式发生改变时，只要改变其映射，就可以使外模式保持不变，对应的应用程序也可保持不变；另一方面，通过模式一内模式映射，定义建立数据的逻辑结构(模式)与存储结构(内模式)间的对应关系，当数据的存储结构发生变化时，只需改变模式一内模式映射，就能保持模式不变，因此应用程序也可以保持不变。

理解MySql事务隔离机制、锁以及各种锁协议 mysql事务隔离三级封锁两段锁MCVV 一直以来对数据库的事务隔离机制的理解总是停留在表面，其内容也是看一遍忘一边。这两天决定从原理上理解它，整理成自己的知识。查阅资料的过程中发现好多零碎的概念如果串起来足够写一本书，所以在这里给自己梳理一个脉络，具体的内容参考引文或在网上搜一下。由于平时接触最多的是MySQL，所以文章中某些部分是MySQL特有的特性，请读者注意。 数据库并发 *** 作会引发的问题： 多个事务同时访问数据库时候，会发生下列5类问题，包括3类数据读问题（脏读，不可重复读，幻读），2类数据更新问题（第一类丢失更新，第二类丢失更新）： 脏读（dirty read）：A事务读取B事务尚未提交的更改数据，并在这个数据基础上 *** 作。如果B事务回滚，那么A事务读到的数据根本不是合法的，称为脏读。在oracle中，由于有version控制，不会出现脏读。 不可重复读（unrepeatable read）：A事务读取了B事务已经提交的更改（或删除）数据。比如A事务第一次读取数据，然后B事务更改该数据并提交，A事务再次读取数据，两次读取的数据不一样。 幻读（phantom read）：A事务读取了B事务已经提交的新增数据。注意和不可重复读的区别，这里是新增，不可重复读是更改（或删除）。这两种情况对策是不一样的，对于不可重复读，只需要采取行级锁防止该记录数据被更改或删除，然而对于幻读必须加表级锁，防止在这个表中新增一条数据。 第一类丢失更新：A事务撤销时，把已提交的B事务的数据覆盖掉。 第二类丢失更新：A事务提交时，把已提交的B事务的数据覆盖掉。 数据库在并发 *** 作下会出现上述这些问题，要解决它就要想办法在执行可能引发问题的 *** 作之前将该 *** 作阻塞住，让它等到合适的时机再执行。那么如何挑选合适的时机阻塞 *** 作的执行，又如何保证在调度过程执行完成后其执行结果与串行执行 *** 作的结果相同呢？ 三级封锁协议 数据库想要在“合适”的时机阻塞住数据库 *** 作，那么首先要定义好怎么样的时机算是“合适”，因为各个系统支持的业务千差万别，对数据的实时性和有效性的要求也不同。于是数据库理论中就提出了封锁级别的概念，对不同的同步要求采用不同的封锁级别。 三级封锁协议内容如下： 一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。 一级封锁协议可以防止丢失修改，并保证事务T是可恢复的。使用一级封锁协议可以解决丢失修改问题。在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，它不能保证可重复读和不读“脏”数据。 二级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后方可释放S锁。 二级封锁协议除防止了丢失修改，还可以进一步防止读“脏”数据。但在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。 三级封锁协议 ：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。 三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。 事务隔离级别： 三级封锁协议反映在实际的数据库系统上，就是四级事务隔离机制。总的来说，四种事务隔离机制就是在逐渐的限制事务的自由度，以满足对不同并发控制程度的要求。以下就是数据库的四种隔离级别： Read Uncommitted、Read Committed、Repeatable Read、Serializable 其对各个并发问题的制约强度见下表： √: 可能出现 ×: 不会出现 脏读 不可重复读 幻读 Read uncommitted √ √ √ Read committed × √ √ Repeatable read × × √ Serializable × × × 四种级别对并发问题的解决由弱到强，相应的系统性能由强到弱，MySQL的默认级别是Repeatable Read。 Read Uncommitted 在Read Uncommitted策略下，数据库遵循一级封锁协议，只对修改数据的并发 *** 作做限制。一个事务不能修改其他事务正在修改的数据，但可以读取到其他事务中尚未提交的修改，这些修改如果未被提交，将会成为脏数据。 Read committed 在Read committed策略下，数据库遵循二级封锁协议，只允许读取已经被提交的数据，反过来讲，如果一个事务修改了某行数据且尚未提交，而第二个事务要读取这行数据的话，那么是不允许的。在MySql的InnoDB下，虽然这种 *** 作不被允许，但MySQL不会阻塞住数据的查询 *** 作，而是会查询出数据被修改之前的备份，返回给客户端。MySQL的这种机制称为MVCC（多版本并发控制），就是说数据库在事务并发的过程中对数据维护多个版本，使得不同的事务对不同的数据版本进行读写（MVCC的实现参见引用中的文章）。这样的机制反映在应用中就是，在任何时候对数据库查询总是可以得到数据库中最近提交的数据。为被提交的脏数据被隔离起来，无法被查询到，即防止脏读发生。 Repeat Read Repeat Read又比Read Committed更加严格一点，但仍然是在二级封锁协议的范畴，只是读取过程受到更多MVCC的影响。在Read Committed下，允许一个事务中多次相同查询得到不同的结果，就是所谓的不可重复读问题。这在一些应用中是允许的，所以oracle、SQL server上默认这一隔离级别，但MySQL没有，它默认Repeat Read级别。在这一级别下，有赖于MVCC，同一个事务中的查询只能查到版本号不高于当前事务版本的数据，即事务只能看到该事务开始前或者被该事物影响的数据。反过来说，这一级别下，不允许事务读取在该事务开始后新提交的数据。即防止了不可重复读的发生。 依靠上面的机制，已经做到了在事务内数据内容的不变，但是不能保证多次查询得到的数据数量一致。因为在一个事务执行的过程中别的事务完全可以执行数据插入，当插入了刚好符合查询条件的数据时，就会引发数据查询结果集增加，引发幻读。还有一种情况就是，如果一个事务想插入一条数据，而另一个事务已经插入了含有相同主键的数据，那么当前事务也会被阻塞，并最终执行失败，虽然当前事务根本无法查询到这一条数据，这也是一种幻读。InnoDB提供的间隙锁机制可以在一定程度上防止幻读的发生，具体介绍见最后一篇引文。 Serializable 最后，最强事务隔离机制Serializable，它遵循三级封锁协议，使得所有的事务必须串行化执行，只要有事务在对表进行查询，那么在此事务提交前，任何其他事务的修改都会被阻塞。这解决了一切并发问题，但会造成大量的等待、阻塞甚至死锁，使系统性能降低。 要注意，在任何一种隔离机制下，都是不允许一个事务删除或修改另一个事务影响过而未提交的数据的。因为事务增、删、改数据以后，会在该行加上排它锁，排它锁会阻塞其他事务再次对该行数据 *** 作。也正是由于排它锁的存在，这四种隔离机制都不会出现任何一种更新丢失的现象，因为一条信息根本不允许第二个事务进行修改。 两段锁协议 数据库在调度并发事务时遵循“两段锁”协议，“两段锁”协议是指所有事务必须分两个阶段对数据项进行加锁和解锁 扩展阶段：在对任何数据项的读、写之前，要申请并获得该数据项的封锁。 收缩阶段：每个事务中，所有的封锁请求必须先于解锁请求。 在数学上可以证明，遵循两段锁的调度可以保证调度结果与串行化调度相同。这样的机制保证了数据库并发调度与串行调度的等价。

以上就是关于sql数据库中事务的并发控制问题 克服两阶段封锁协议的问题是采用变体严格两阶段封锁协议或者强两阶段全部的内容，包括:sql数据库中事务的并发控制问题 克服两阶段封锁协议的问题是采用变体严格两阶段封锁协议或者强两阶段、几个关于数据库基本原理的简答题、高分求答案、DBGrid直接 *** 作，只容许新增，不容许修改怎么实现等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！