数据库中用户对‘脏数据’的读出是什么规则收到了破坏

就是事务完整性受到了破坏

一般现在主流的数据库比如oracle，db2都会通过锁机制来减少脏数据的产生

就是不同session之间由于某个seesion对表进行 *** 作而影响其他session的查询结果

常见并发一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。

丢失修改

下面先来看一个例子，说明并发 *** 作带来的数据的不一致性问题。

考虑飞机订票系统中的一个活动序列:

甲售票点（甲事务）读出某航班的机票余额A,设A=16

乙售票点（乙事务）读出同一航班的机票余额A,也为16

甲售票点卖出一张机票,修改余额A←A-1所以A为15,把A写回数据库

乙售票点也卖出一张机票,修改余额A←A-1所以A为15,把A写回数据库

结果明明卖出两张机票，数据库中机票余额只减少1。

归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（214数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是：

不可重复读

不可重复读是指事务T1读取数据后，事务T2执行更新 *** 作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况：

事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200，与第一次读取值不一致。

事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神密地消失了。

事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。（这也叫做幻影读）

读"脏"数据

读"脏"数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤消，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为"脏"数据，即不正确的数据。

产生上述三类数据不一致性的主要原因是并发 *** 作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发 *** 作，使一个用户事务的执行不受其它事务的干扰，从而避免造成数据的不一致性。

主要由：数据定义、数据 *** 作、数据库的运行管理、数据组织、存储与管理、数据库的保护、数据库的维护、通信。

主要功能：

1、数据定义：供用户定义数据库的三级模式结构、两级映像以及完整性约束和保密限制等约束。DDL主要用于建立、修改数据库的库结构。

2、数据 *** 作：DBMS提供数据 *** 作语言DML（Data Manipulation Language），供用户实现对数据的追加、删除、更新、查询等 *** 作。

3、数据库的运行管理：数据库的运行管理功能是DBMS的运行控制、管理功能，包括多用户环境下的并发控制、安全性检查和存取限制控制、完整性检查和执行、运行日志的组织管理、事务的管理和自动恢复，即保证事务的原子性。这些功能保证了数据库系统的正常运行。

4、数据组织、存储与管理：DBMS要分类组织、存储和管理各种数据，包括数据字典、用户数据、存取路径等，需确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。

5、数据库的保护：数据库中的数据是信息社会的战略资源，所以数据的保护至关重要。DBMS对数据库的保护通过4个方面来实现：数据库的恢复、数据库的并发控制、数据库的完整性控制、数据库安全性控制。

6、数据库的维护：这一部分包括数据库的数据载入、转换、转储、数据库的重组合重构以及性能监控等功能，这些功能分别由各个使用程序来完成。

7、通信：DBMS具有与 *** 作系统的联机处理、分时系统及远程作业输入的相关接口，负责处理数据的传送。

扩展资料：

选择数据库管理系统时应从以下几个方面予以考虑：

1、 构造数据库的难易程度。

需要分析数据库管理系统有没有范式的要求，即是否必须按照系统所规定的数据模型分析现实世界，建立相应的模型；数据库管理语句是否符合国际标准，符合国际标准则便于系统的维护、开发、移植；有没有面向用户的易用的开发工具；所支持的数据库容量，数据库的容量特性决定了数据库管理系统的使用范围。

2、 程序开发的难易程度。

有无计算机辅助软件工程工具CASE——计算机辅助软件工程工具可以帮助开发者根据软件工程的方法提供各开发阶段的维护、编码环境，便于复杂软件的开发、维护。

3、数据库管理系统的性能分析。

包括性能评估（响应时间、数据单位时间吞吐量）、性能监控（内外存使用情况、系统输入/输出速率、SQL语句的执行，数据库元组控制）、性能管理（参数设定与调整）。

参考资料来源：百度百科--数据库管理系统

事务是一系列的数据库 *** 作，是数据库应用程序的基本逻辑单元，也是恢复和并发控制的基本单位。事务处理技术主要包括数据库恢复技术和并发控制技术。本篇博文主要总结下并发控制技术。

事务：是用户定义的一个数据库 *** 作序列，这些 *** 作要么全做，要么全不做，是一个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。一般来说，一个程序中包含多个事务。

ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：

A:原子性(Atomicity): 事务是一个或多个行为捆绑在一起组成一个单独的工作单元,事务中的动作要不都发生,要不都不发生。

C:一致性(Consistent): 即在事务开始之前和结束之后,数据库的完整性约束没有被破坏。

　数据库层面:在一个事务执行前和执行后,数据会符合你设置的约束(例如unique约束,foreign key约束,check约束等)和触发器设置由数据库进行保证

补充楼主：

其实我没什么经验，只不过是了解一些基础的东西罢了。

一楼的 一朵瘩红花 实际经验很丰富，你可以向她咨询一下。

你问的问题挺好得。三个概念紧密联系在一起。

这样说吧：并发的几个事务同时发生，不加锁控制的话数据就会乱套了，而加了锁后，又是并发访问会出现死锁，所以就会出现避免死锁的一些措施。

首先谈并发：理论指的是在一段时间同时对某件事进行 *** 作。 注意精度问题，修改数据库是在一段时间内 *** 作，不是在某个时刻，而日志则会从 时刻 开始记录你的 *** 作。

造成死锁的原因是为了防止 不同的用户同时间（不是时刻）都对某个数据修改，造成访问不一致的问题。

比如你读了数据库的一个数据然后把它修改了并存回去，是需要时间的（假如是student表中的有个grade属性，你改了一条记录的一个值）在这个过程当中，有人又访问了数据库并且恰恰访问的是存回去之前的数据，然后他要进行 *** 作，过了一段时间，此时你已经存回去了数据。会发现原来的数据被改动了。这时数据就乱套了。（专业术语叫读脏数据，其实还有很多其他类似这种导致前后数据不一致的问题）所以为了限定这种 *** 作，数据库设计了-----锁---来锁定这种 *** 作。就是你正在 *** 作某个数据的时候----通常之前会先锁定这个数据，这样别人就不能对此数据 *** 作了（严格来说就是只能读，不能改），必须等你 *** 作完才能对此数据修改等 *** 作，这就在一定程度上避免了前后 *** 作数据不一致的问题。

但是有了锁后，新问题出现了，就是死锁：

简单解释死锁：进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁

官方解释死锁

死锁，根本原因在于对共享存储区的访问。在数据库中也一样，如果需要“修改”一条数据，首先数据库管理系统会在上面加锁，以保证在同一时间只有一个事务能进行修改 *** 作。锁有多种实现方式，比如意向锁，共享－排他锁，锁表，树形协议，时间戳协议等等。锁还有多种粒度，比如可以在表上加锁，也可以在记录上加锁。

在并发控制中，锁是非常重要的。

至于在Oracle还是别的数据库管理系统中，死锁产生的原因没有不同，不同的顶多是锁的实现或者死锁的恢复等罢了

再来说说事务：

事务简单来说就是 一系列的对数据库的 *** 作揉在一起，要么同时完成，要么就都不完成。

比如---你要取钱的过程就可以当成是一个小的事务： 插卡，输入取钱金额，取走钱，拿出来卡。此过程缺一不可。把所有这些过程细节封装起来就成为一个事务。

以oracle数据库为例：

一个事务（你可以认为是一系列业务的 *** 作）起始于dml语句（insert、update、delete）

即一条dml语句就做为一个事务的起始，然后根据业务需要，进行其他的dml *** 作都算是事务的一部分。

最后碰到commit。或者rollback，或者其他意外什么的都算作一个事务的结束。

整个过程就是一个事务。

事务的理论解释就是那四个什么特性：什么原子性、一致性、隔离性和持久性

简称ACID

剩下的：数据库是建立在 *** 作系统之上的一个层次。

你问的是数据库的存储机制？？工作机制？？还是什么的？？

数据库就是存数据的。数据库管理系统是 对存的数据进行高效率的管理

大的结构分物理数据跟逻辑数据。

物理数据就是数据在存储设备上的存储方式，什么物理联系，物理结构，物理记录等 术语。

逻辑数据就是程序员和用户看到的数据形式。什么逻辑联系，逻辑结构==同上

数据库管理类系统就是把这些逻辑跟物理相互转换。 好比你输入的叫逻辑数据存储在磁盘上叫物理数据。等等。

废话了一堆，也不知道回答对你的问题没~~

数据库锁的产生原因及解决办法

数据库和 *** 作系统一样，是一个多用户使用的共享资源。当多个用户并发地存取数据 时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发 *** 作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并 发控制的一个非常重要的技术。在实际应用中经常会遇到的与锁相关的异常情况，当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就会出现死锁，严 重影响应用的正常执行。

在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两 种基本的锁类型来对数据库的事务进行并发控制。

死锁的第一种情况

一个用户A 访问表A(锁住了表A),然后又访问表B；另一个用户B 访问表B(锁住了表B)，然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

解决方法：

这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表 *** 作时，尽量按照相同的顺序进 行处理，尽量避免同时锁定两个资源，如 *** 作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

死锁的第二种情况

用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A 有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项 目中经常发生。如在某项目中，页面上的按钮点击后，没有使按钮立刻失效，使得用户会多次快速点击同一按钮，这样同一段代码对数据库同一条记录进行多次 *** 作，很容易就出现这种死锁的情况。

解决方法：

1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录 *** 作。

2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B *** 作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新 *** 作不受我们系统的控制，因此可能会造 成脏数据被更新到数据库中。

3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证 *** 作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统， 当某个 *** 作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个 *** 作过程中（从 *** 作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括 *** 作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。

死锁的第三种情况

如果在事务中执行了一条不满足条件的update语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁和阻塞。类似的情 况还有当表中的数据量非常庞大而索引建的过少或不合适的时候，使得经常发生全表扫描，最终应用系统会越来越慢，最终发生阻塞或死锁。

解决方法：

SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。

5．小结

总体上来说，产生内存溢出与锁表都是由于代码写的不好造成的，因此提高代码的质量是最根本的解决办法。有的人认为先把功能实现，有BUG时再在测试阶段进 行修正，这种想法是错误的。正如一件产品的质量是在生产制造的过程中决定的，而不是质量检测时决定的，软件的质量在设计与编码阶段就已经决定了，测试只是 对软件质量的一个验证，因为测试不可能找出软件中所有的BUG。

脏读dirty reads：当事务读取还未被提交的数据时，就会发生这种事件。举例来说：Transaction 1 修改了一行数据，然后 Transaction 2 在 Transaction 1 还未提交修改 *** 作之前读取了被修改的行。如果 Transaction 1 回滚了修改 *** 作，那么 Transaction 2 读取的数据就可以看作是从未存在过的。

不可重复的读non-repeatable reads：当事务两次读取同一行数据，但每次得到的数据都不一样时，就会发生这种事件。举例来说：Transaction 1 读取一行数据，然后 Transaction 2 修改或删除该行并提交修改 *** 作。当 Transaction 1 试图重新读取该行时，它就会得到不同的数据值（如果该行被更新）或发现该行不再存在（如果该行被删除）。

虚读phantom read：如果符合搜索条件的一行数据在后面的读取 *** 作中出现，但该行数据却不属于最初的数据，就会发生这种事件。举例来说：Transaction 1 读取满足某种搜索条件的一些行，然后 Transaction 2 插入了符合 Transaction 1 的搜索条件的一个新行。如果 Transaction 1 重新执行产生原来那些行的查询，就会得到不同的行。

MYSQL事务隔离级别的认识

2010-08-06 10:27

在hibernate中如果要连续不间断的保存多个实体的实例，那么在我们保存第一个的时候，其实在数据库里是不存在数据的，即使用Sessionflush()也无济于事，这到底是怎么回事呢？让我很是疑惑

在查阅了相关的资料后，原来是数据库对于事务的隔离级别的限制问题，而我原来的MYSQL数据库正好是不支持我上述 *** 作的隔离级别。

1、在MYSQL中查询事务隔离级别：

select @@tx_isolation;（tx其实就是transaction的缩写或者习惯缩写法）

我的结果是REPEATABLE-READ（即可重复读，稍后会引用专业结束文档）

2、修改MYSQL事务隔离界别：

set transaction isolation level 目标隔离级别;

3、再次查询隔离级别进行检验是否已经成功修改。

这样在修改了隔离级别之后，在进行save()的时候，数据库中就会存在一些数据了，问题解决了。关于其他的数据库产品，思想都是一样的。

附加、官方的SQL事务隔离级别文档：

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（可串行化）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

以上就是关于数据库中用户对‘脏数据’的读出是什么规则收到了破坏全部的内容，包括:数据库中用户对‘脏数据’的读出是什么规则收到了破坏、什么是 *** 作不能重复读 丢失修改 读"脏"数据、数据库DBMS的主要组成部分是什么各部分的主要功能是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！