数据库原子性，数据库事务里的原子性和一致性的区别

各位老铁们好，相信很多人对数据库原子性都不是特别的了解，因此呢，今天就来为大家分享下关于数据库原子性以及数据库事务里的原子性和一致性的区别的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

在关系数据库模型中,什么是关系的原子性

在关系数据模型中，关系可以看成由行和列交叉组成的二维表格，表中一行称为一个元组，可以用来标识实体集中的一个实体。表中的列称为属性，给每一列起一个名称即为属性名，表中的属性名不能相同。

列的取值范围称为域，同列具有相同的域，不同的列也可以有相同的域。表中任意两行（元组）不能相同。能唯一标识表中不同行的属性或属性组称为主键。

尽管关系与传统的二维表格数据文件具有类似之处，但是它们又有区别，严格地说，关系是一种规范化的二维表格！

事务的原子性是指

问题一：事物的原子性是指 A事务的原子性是指事务的所有操纵在数据库中要么全部正确反映出来，要么全部不反映。选项B)指的是持久性。选项C)指的是隔离性。选项D)指的是一致性。

希望采纳

问题二：数据库事务原子性，一致性是怎样实现的这个问题的有趣之处，不在于问题本身（“原子性、一致性的实现机制是什么”），而在于回答者的分歧反映出来的另外一个问题：原子性和一致性之间的关系是什么？

我特别关注了@我练功发自真心

的答案，他正确地指出了，为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制。但这个答案仍然是不完整的，因为原子性并不能够完全保证一致性。

按照我个人的理解，在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。

首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。

在

数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在

同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即

在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。

为了实现原子性，需要通过日志：将所有对

数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已

经执行成功的操作撤销，从而达到“全部操作失败”的目的。最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crash

recovery的过程：读取日志进行REDO（重演将所有已经执行成功但尚未写入到磁盘的操作，保证持久性），再对所有到崩溃时尚未成功提交的事务进行

UNDO（撤销所有执行了一部分但尚未提交的操作，保证原子性）。crash

recovery结束后，数据库恢复到一致性状态，可以继续被使用。

日志的管理和重演是数据库实现中最复杂的部分之一。如果涉及到并行处理和分布式系统（日志的复制和重演是数据库高可用性的基础），会比上述场景还要复杂得多。

但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果。例如，事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上100。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了100元。那么最后的结果应该是A增加了200元。但事实上，

事务1最终完成后，帐号A只增加了100元，因为事务2的修改结果被事务1覆盖掉了。

为了保证并***况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。怎样实现隔离性，已经有很多人回答过了，原则上无非是两种类型的锁：

一

种是悲观锁，即当前事务将所有涉及操作的对象加锁，操作完成后释放给其它对象使用。为了尽可能提高性能，发明了各种粒度（数据库级/表级/行级……）/各

种性质（共享锁/排他锁/共享意向锁/排他意向锁/共享排他意向锁……）的锁。为了解决死锁问题，又发明了两阶段锁协议/死锁检测等一系列的技术。

一种是乐观锁，即不同的事务可以同时看到同一对象（一般是数据行）的不同历史版本。如果有两个事务同时......>>

问题三：什么是事务，事务的四个特性是什么事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。

事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。

二．事务的 ACID

事务具有四个特征：原子性（ Atomicity）、一致性（ Consistency）、隔离性（ Isolation）和持续性（ Durability）。这四个特性简称为 ACID特性。

1、原子性

事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做

2、一致性

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

3、隔离性

一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

4、持续性

也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

h7 g

问题四：sql server事务的原子性是什么意思，有没有具体的例子帮忙解释一下，谢谢更新A表

更新B表

。。。

--------------------

更新B表时，发生错误，此时A表已更新完了，这样数据就不整合了

这样就需要用【事务】去控制了，要更新，就全部更新，发生错误，全部回滚

所以说不可分割，具有原子性

问题五：既然原子可以再分，为什么说事务是原子性的因为事物是由原子直接构成的，给你打个比方：社会是人构成的，但是人就像原子一样，还可以再分啊，细胞还更小呢！

问题六：数据库事务里的原子性和一致性的区别 5分原子性，一个事务要么完全提交要么完全回滚，不会介于2者之间。

一致性，一个查询发起后，不管数据发生了多少变化多少事务，查询结果应当为发起查询时间一致的数据

问题七：数据库事务四大特性是什么？事务的：原子性、一致性、分离性、持久性原子性、一致性、分离性、持久性(1)原子性事务的原子性指的是，事务中包含的程序作为数据库的逻辑工作单位，它所做的对数据修改操作要么全部执行，要么完全不执行。这种特性称为原子性。事务的原子性要求，如果把一个事务可看作是一个程序，它要么完整的被执行，要么完全不执行。就是说事务的操纵序列或者完全应用到数据库或者完全不影响数据库。这种特性称为原子性。假如用户在一个事务内完成了对数据库的更新，这时所有的更新对外部世界必须是可见的，或者完全没有更新。前者称事务已提交，后者称事务撤消（或流产）。DBMS必须确保由成功提交的事务完成的所有操纵在数据库内有完全的反映，而失败的事务对数据库完全没有影响。(2)一致性事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。一致性处理数据库中对所有语义约束的保护。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。例如，当数据库处于一致性状态S1时，对数据库执行一个事务，在事务执行期间假定数据库的状态是不一致的，当事务执行结束时，数据库处在一致性状态S2。(3)分离性分离性指并发的事务是相互隔离的。即一个事务内部的操作及正在操作的数据必须封锁起来，不被其它企图进行修改的事务看到。分离性是DBMS针对并发事务间的冲突提供的安全保证。DBMS可以通过加锁在并发执行的事务间提供不同级别的分离。假如并发交叉执行的事务没有任何控制，操纵相同的共享对象的多个并发事务的执行可能引起异常情况。DBMS可以在并发执行的事务间提供不同级别的分离。分离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可分离性可能会带来较高的冲突和较多的事务流产。流产的事务要消耗资源，这些资源必须要重新被访问。因此，确保高分离级别的DBMS需要更多的开销。(4)持久性持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即一旦一个事务提交，DBMS保证它对数据库中数据的改变应该是永久性的，耐得住任何系统故障。持久性通过数据库备份和恢复来保证。持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即对已提交事务的更新能恢复。一旦一个事务被提交，DBMS必须保证提供适当的冗余，使其耐得住系统的故障。

问题八：什么是事务？事务的特性有哪些？事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。

例如：在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。

特性事务是恢复和并发控制的恭本单位。

事务应该具有4个属性：原子性、一致性、隔离性、持续性。这四个属性通常称为ACID特性。

原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。

一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性（durability）。持续性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

问题九：什么是程序的原子性举个例子：

A想要从自己的帐户中转1000块钱到B的帐户里。那个从A开始转帐，到转帐结束的这一个过程，称之为一个事务。在这个事务里，要做如下操作：

1.从A的帐户中减去1000块钱。如果A的帐户原来有3000块钱，现在就变成2000块钱了。

2.在B的帐户里加1000块钱。如果B的帐户如果原来有2000块钱，现在则变成3000块钱了。

如果在A的帐户已经减去了1000块钱的时候，忽然发生了意外，比如停电什么的，导致转帐事务意外终止了，而此时B的帐户里还没有增加1000块钱。那么，我们称这个操作失败了，要进行回滚。回滚就是回到事务开始之前的状态，也就是回到A的帐户还没减1000块的状态，B的帐户的原来的状态。此时A的帐户仍然有3000块，B的帐户仍然有2000块。

我们把这种要么一起成功（A帐户成功减少1000，同时B帐户成功增加1000），要么一起失败（A帐户回到原来状态，B帐户也回到原来状态）的操作叫原子性操作。

如果把一个事务可看作是一个程序,它要么完整的被执行,要么完全不执行。这种特性就叫原子性

问题十：面试题 java什么叫事务，事务有什么用事务是什么？

事务是作为一个逻辑单元执行的一系列操作，一个逻辑工作单元必须有四个属性，称为 ACID（原子性、一致性、隔离性和持久性）属性，只有这样才能成为一个事务：

原子性

事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。

一致性

事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B树索引或双向链表）都必须是正确的。

隔离性

由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。

持久性

事务完成之后，它对于系统的影响是永久性的。该修改即使出现系统故障也将一直保持。

什么是程序的原子性

程序的原子性指：整个程序中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。

原子性在一个操作是不可中断的，要么全部执行成功要么全部执行失败，有着“同生共死”的感觉。及时在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程所干扰。

如果要保证原子性，必须符合以下两条规则：

1、运算结果并不依赖于变量的当前值，或者能够确保只有一个线程修改变量的值。

2、变量不需要与其他的状态变量共同参与不变约束。

扩展资料：

数据库事务正确执行的四个基本要素

一、原子性（Atomicity）

整个程序中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。

二、一致性（Consistency）

一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。

三、隔离性（Isolation）

隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。

四、持久性（Durability）

在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

参考资料：百度百科-acid

数据库事务里的原子性和一致性的区别

这个问题的有趣之处，不在于问题本身（“原子性、一致性的实现机制是什么”），而在于回答者的分歧反映出来的另外一个问题：原子性和一致性之间的关系是什么？

我特别关注了@我练功发自真心

的答案，他正确地指出了，为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制。但这个答案仍然是不完整的，因为原子性并不能够完全保证一致性。

按照我个人的理解，在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。

首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。

在

数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在

同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即

在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。

为了实现原子性，需要通过日志：将所有对

数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已

经执行成功的操作撤销，从而达到“全部操作失败”的目的。最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crash

recovery的过程：读取日志进行REDO（重演将所有已经执行成功但尚未写入到磁盘的操作，保证持久性），再对所有到崩溃时尚未成功提交的事务进行

UNDO（撤销所有执行了一部分但尚未提交的操作，保证原子性）。crash

recovery结束后，数据库恢复到一致性状态，可以继续被使用。

日志的管理和重演是数据库实现中最复杂的部分之一。如果涉及到并行处理和分布式系统（日志的复制和重演是数据库高可用性的基础），会比上述场景还要复杂得多。

但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果。例如，事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上100。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了100元。那么最后的结果应该是A增加了200元。但事实上，

事务1最终完成后，帐号A只增加了100元，因为事务2的修改结果被事务1覆盖掉了。

为了保证并发情况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。怎样实现隔离性，已经有很多人回答过了，原则上无非是两种类型的锁：

一

种是悲观锁，即当前事务将所有涉及操作的对象加锁，操作完成后释放给其它对象使用。为了尽可能提高性能，发明了各种粒度（数据库级/表级/行级……）/各

种性质（共享锁/排他锁/共享意向锁/排他意向锁/共享排他意向锁……）的锁。为了解决死锁问题，又发明了两阶段锁协议/死锁检测等一系列的技术。

一种是乐观锁，即不同的事务可以同时看到同一对象（一般是数据行）的不同历史版本。如果有两个事务同时修改了同一数据行，那么在较晚的事务提交时进行冲突

检测。实现也有两种，一种是通过日志UNDO的方式来获取数据行的历史版本，一种是简单地在内存中保存同一数据行的多个历史版本，通过时间戳来区分。

锁也是数据库实现中最复杂的部分之一。同样，如果涉及到分布式系统（分布式锁和两阶段提交是分布式事务的基础），会比上述场景还要复杂得多。

@

我练功发自真心

提到，其他回答者说的其实是操作系统对atomic的理解，即并发控制。我不能完全同意这一点。数据库有自己的并发控制和锁问题，虽然在原理上和操作系统

中的概念非常类似，但是并不是同一个层次上的东西。数据库中的锁，在粒度/类型/实现方式上和操作系统中的锁都完全不同。操作系统中的锁，在数据库实现中

称为latch（一般译为闩）。其他回答者回答的其实是“在并行事务处理的情况下怎样保证数据的一致性”。

最后回到原来的问题（“原子性、一致性的实现机制是什么”）。我手头有本Database

System

Concepts（4ed，有点老了），在第15章的开头简明地介绍了ACID的概念及其关系。如果你想从概念上了解其实现，把这本书的相关章节读完应该能大概明白。如果你想从实践上了解其实现，可以找innodb这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对操作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！