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

各位老铁们，大家好，今天由我来为大家分享数据库的原子性，以及数据库事务里的原子性和一致性的区别的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！

事务的原子性是指什么

事务的原子性是指一个事务中的所有操作是不可分割的，必须是一个逻辑单元，只能是全部执行成功或者全部执行失败。

事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现两种状态之一，要么都成功，要么都失败任何一项操作都会导致整个事务的失败，同时其它已经被执行的操作都将被撤销并回滚，只有所有的操作全部成功，整个事务才算是成功完成。

事务原子性是如何保证的

MySQL事务的原子性是通过undo log来实现的。磁盘存数据采用的是随机存储的方式，这就使得在存放数据的时候不仅需要记录下存放的数据值，还需要记录存放数据的地址，存储速度相对比较慢。而日志存储是连续存储，因此在存数据的时候只需要记录下首地址即可，其余数据记录偏移量，可以进一步提高性能。

每一个写事务，都会修改BufferPool，从而产生相应的Redo/Undo日志，这些日志信息会被记录到日志文件中。在MySQL中，任何BufferPool中的页被刷新到磁盘之前，都会先写入到日志文件中，如果BufferPool中的数据提交，此时数据库挂了，那么在数据库再次启动之后，就可以通过Redo日志来将其恢复出来，以此来保证写的数据不会丢失。

如果数据没有提交，此时数据库挂了，就需要通过Undo日志来实现。每一条数据变更（insert/update/delete）操作都伴随一条undo log的生成，并且回滚日志必须先于数据持久化到磁盘上。所谓的回滚就是根据回滚日志做逆向操作，比如delete的逆向操作为insert，insert的逆向操作为delete，update的逆向为update等。

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

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

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

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

什么是程序的原子性

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

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

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

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这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对操作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。

好了，文章到此结束，希望可以帮助到大家。