简述数据库中事务的概念和特点

是指作为单个逻辑工作单元执行的一系列 *** 作，要么完整地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有 *** 作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关 *** 作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。

ACID，指数据库事务正确执行的四个基本要素的缩写包含:原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性,交易过程极可能达不到交易方的要求

原子性

整个事务中的所有 *** 作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性

在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

隔离性

两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

持久性

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

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

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

的答案，他正确地指出了，为了保证事务 *** 作的原子性，必须实现基于日志的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这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对 *** 作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。

回答的有点多请耐心看完。

希望能帮助你还请及时采纳谢谢

1事务的原理

事务就是将一组SQL语句放在同一批次内去执行，如果一个SQL语句出错,则该批次内的所有SQL都将被取消执行。MySQL事务处理只支持InnoDB和BDB数据表类型。

1事务的ACID原则

1（Atomicity）原子性： 事务是最小的执行单位，不允许分割。原子性确保动作要么全部完成，要么完全不起作用；

2（Consistency）一致性： 执行事务前后，数据保持一致；

3（Isolation）隔离性： 并发访问数据库时，一个事务不被其他事务所干扰。

4（Durability）持久性: 一个事务被提交之后。对数据库中数据的改变是持久的，即使数据库发生故障。

1缓冲池（Buffer Pool）

Buffer Pool中包含了磁盘中部分数据页的映射。当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。

2日志缓冲区（Log Buffer）

当在MySQL中对InnoDB表进行更改时，这些更改命令首先存储在InnoDB日志缓冲区（Log Buffer）的内存中，然后写入通常称为重做日志（redo logs）的InnoDB日志文件中。

3双写机制缓存（DoubleWrite Buffer）

Doublewrite Buffer是共享表空间的物理文件的 buffer,其大小是2MB是一个一分为二的2MB空间。

刷脏 *** 作开始之时,先进行脏页‘备份’ *** 作将脏页数据写入 Doublewrite Buffer

将Doublewrite Buffer(顺序IO)写入磁盘文件中(共享表空间) 进行刷脏 *** 作

4回滚日志(Undo Log)

Undo Log记录的是逻辑日志记录的是事务过程中每条数据的变化版本和情况

在Innodb 磁盘架构中Undo Log 默认是共享表空间的物理文件的Buffer

在事务异常中断,或者主动(Rollback)回滚的过程中 ,Innodb基于 Undo Log进行数据撤销回滚,保证数据回归至事务开始状态

5重做日志(Redo Log)

Redo Log通常指的是物理日志，记录的是数据页的物理修改并不记录行记录情况。（也就是只记录要做哪些修改，并不记录修改的完成情况） 当数据库宕机重启的时候，会将重做日志中的内容恢复到数据库中。

1原子性

Innodb事务的原子性保证,包含事务的提交机制和事务的回滚机制在Innodb引擎中事务的回滚机制是依托 回滚日志(Undo Log) 进行回滚数据，保证数据回归至事务开始状态

2那么不同的隔离级别，隔离性是如何实现的，为什么不同事物间能够互不干扰？ 答案是 锁 和 MVCC。

3持久性

基于事务的提交机制流程有可能出现三种场景

1 数据刷脏正常一切正常提交，Redo Log 循环记录数据成功落盘持久性得以保证

2数据刷脏的过程中出现的系统意外导致页断裂现象 (部分刷脏成功)，针对页断裂情况,采用Double write机制进行保证页断裂数据的恢复

3数据未出现页断裂现象,也没有刷脏成功，MySQL通过Redo Log 进行数据的持久化即可

4一致性

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性

2事务的隔离级别

Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别

脏读： 指一个事务读取了另外一个事务未提交的数据。

不可重复读： 在一个事务内读取表中的某一行数据，多次读取结果不同

虚读(幻读)： 是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。

2基本语法

-- 使用set语句来改变自动提交模式

SET autocommit = 0; /关闭/

SET autocommit = 1; /开启/

-- 注意:

--- 1MySQL中默认是自动提交

--- 2使用事务时应先关闭自动提交

-- 开始一个事务,标记事务的起始点

START TRANSACTION

-- 提交一个事务给数据库

COMMIT

-- 将事务回滚,数据回到本次事务的初始状态

ROLLBACK

-- 还原MySQL数据库的自动提交

SET autocommit =1;

-- 保存点

SAVEPOINT 保存点名称 -- 设置一个事务保存点

ROLLBACK TO SAVEPOINT 保存点名称 -- 回滚到保存点

RELEASE SAVEPOINT 保存点名称 -- 删除保存点

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

/

课堂测试题目

A在线买一款价格为500元商品,网上银行转账

A的yhk余额为2000,然后给商家B支付500

商家B一开始的yhk余额为10000

创建数据库shop和创建表account并插入2条数据

/

CREATE DATABASE `shop`CHARACTER SET utf8 COLLATE utf8_general_ci;

USE `shop`;

CREATE TABLE `account` (

`id` INT(11) NOT NULL AUTO_INCREMENT,

`name` VARCHAR(32) NOT NULL,

`cash` DECIMAL(9,2) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=INNODB DEFAULT CHARSET=utf8

INSERT INTO account (`name`,`cash`)

VALUES('A',200000),('B',1000000)

-- 转账实现

SET autocommit = 0; -- 关闭自动提交

START TRANSACTION; -- 开始一个事务,标记事务的起始点

UPDATE account SET cash=cash-500 WHERE `name`='A';

UPDATE account SET cash=cash+500 WHERE `name`='B';

COMMIT; -- 提交事务

# rollback;

SET autocommit = 1; -- 恢复自动提交

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

3事务实现方式-MVCC

1什么是MVCC

MVCC是mysql的的多版本并发控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别为RR（可重复读）和RC（读提交）生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突，极大的增加了系统的并发性能。

2MVCC的实现机制

InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。

在多版本并发控制中，为了保证数据 *** 作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被 *** 作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的；对于数据的更新（包括增删改） *** 作成功，会将这个版本号更新到数据的行中；事务提交成功，新的版本号也就更新到了此数据行中。这样保证了每个事务 *** 作的数据，都是互不影响的，也不存在锁的问题。

3MVCC下的CRUD

SELECT：

当隔离级别是REPEATABLE READ时select *** 作，InnoDB每行数据来保证它符合两个条件：

1 事务的版本号 大于等于 创建行版本号

　 2 行数据的删除版本 未定义 或者大于 事务版本号

　 行创建版本号 事务版本号 行删除版本号

INSERT：

InnoDB为这个新行 记录 当前的系统版本号。

DELETE：

InnoDB将当前的系统版本号 设置为 这一行的删除版本号。

UPDATE：

InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为 当前的系统版本号。它同时也会将这个版本号 写到 旧行的删除版本里。

————————————————

版权声明：本文为CSDN博主「@Autowire」的原创文章，遵循CC 40 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：>

以上就是关于简述数据库中事务的概念和特点全部的内容，包括:简述数据库中事务的概念和特点、数据库事务级别、数据库事务里的原子性和一致性的区别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！