数据库相关的一个必须要清楚的知识点：事务

对于小白来说，听到前辈们总是提到事务这个概念，但自己不太懂，所以抽时间大量的查询资料，详细了解了一下事务的相关概念，下面就详细简述一下事务。

**

• 什么是事务？

**
事务是数据库系统中的重要概念,了解这一概念是以正确的方式开发和数据库交互的应用程序的前提。
定义:数据库事务是构成单一逻辑工作单元的操作集合。
事务具备四个特性：
1.原子性（Atomicity）：
事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
2.一致性（Consistency）：
事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。
3.隔离性（Isolation）：
多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
4.持久性（Durability）：
一个事务一旦提交，他对数据库的修改应该永久保存在数据库中。

对上面四种特性的理解举例说明：

用一个常用的“A账户向B账号汇钱”的例子来说明如何通过数据库事务保证数据的准确性和完整性。熟悉关系型数据库事务的都知道从帐号A到帐号B需要6个操作：

1、从A账号中把余额读出来（500）。
2、对A账号做减法操作（500-100）。
3、把结果写回A账号中（400）。
4、从B账号中把余额读出来（500）。
5、对B账号做加法操作（500+100）。
6、把结果写回B账号中（600）。

原子性：

保证1-6所有过程要么都执行，要么都不执行。一旦在执行某一步骤的过程中发生问题，就需要执行回滚操作。 假如执行到第五步的时候，B账户突然不可用（比如被注销），那么之前的所有操作都应该回滚到执行事务之前的状态。

一致性

在转账之前，A和B的账户中共有500+500=1000元钱。在转账之后，A和B的账户中共有400+600=1000元。也就是说，数据的状态在执行该事务操作之后从一个状态改变到了另外一个状态。同时一致性还能保证账户余额不会变成负数等。

隔离性

在A向B转账的整个过程中，只要事务还没有提交（commit），查询A账户和B账户的时候，两个账户里面的钱的数量都不会有变化。
如果在A给B转账的同时，有另外一个事务执行了C给B转账的操作，那么当两个事务都结束的时候，B账户里面的钱应该是A转给B的钱加上C转给B的钱再加上自己原有的钱。

持久性

一旦转账成功（事务提交），两个账户的里面的钱就会真的发生变化（会把数据写入数据库做持久化保存）！

事务的原子性与一致性缺一不可。

• 上面我们简单了解了一下事务的相关概念,那下面我们来了解下上图中由隔离性和一致性共同组成的并发控制这一属性以及有原子性和持久性共同组成的日志恢复这一属性。

并发控制：
在讲解并发控制技术前,先简单介绍下数据库常见的并发异常。
- 脏读：
事务A访问了数据库，它干了一件事情，往数据库里加上了新来的牛人的名字，但是没有提交事务。

insert into T values (4, '牛D');

这时，来了另一个事务B，他要查询所有牛人的名字。

select Name from T;

这时，如果没有事务之间没有有效隔离，那么事务B返回的结果中就会出现“牛D”的名字。这就是“脏读（dirty read）”。

- 不可重复读（unrepeatable read）：
事务A访问了数据库，他要查看ID是1的牛人的名字，于是执行了

select Name from T where ID = 1;

这时，事务B来了，因为ID是1的牛人改名字了，所以要更新一下，然后提交了事务。

update T set Name = '不牛' where ID = 1;

接着，事务A还想再看看ID是1的牛人的名字，于是又执行了

select Name from T where ID = 1;

结果，两次读出来的ID是1的牛人名字竟然不相同，这就是不可重复读（unrepeatable read）。

• 幻读（phantom problem）

事务A访问了数据库，他想要看看数据库的牛人都有哪些，于是执行了

select * from T;

这时候，事务B来了，往数据库加入了一个新的牛人。

insert into T values(4, '牛D');

这时候，事务A忘了刚才的牛人都有哪些了，于是又执行了。

select * from T;

结果，第一次有三个牛人，第二次有四个牛人。
相信这个时候事务A就蒙了，刚才发生了什么？这种情况就叫“幻读（phantom problem）”。

以上就是数据库可能发生的异常，为了防止出现脏读、不可重复读、幻读等情况，我们就需要根据我们的实际需求来设置数据库的隔离级别。
事务的隔离性：
事务具有隔离性,理论上来说事务之间的执行不应该相互产生影响,其对数据库的影响应该和它们串行执行时一样。

然而完全的隔离性会导致系统并发性能很低,降低对资源的利用率,因而实际上对隔离性的要求会有所放宽,这也会一定程度造成对数据库一致性要求降低

SQL标准为事务定义了不同的隔离级别,从低到高依次是：

1. 读未提交(READ UNCOMMITTED)
2. 读已提交(READ COMMITTED)
3. 可重复读(REPEATABLE READ)
4. 串行化(SERIALIZABLE)

事务的隔离级别越低,可能出现的并发异常越多,但是通常而言系统能提供的并发能力越强。

不同的隔离级别与可能的并发异常的对应情况如下表所示,有一点需要强调,这种对应关系只是理论上的,对于特定的数据库实现不一定准确,比如mysql
的Innodb存储引擎通过Next-Key Locking技术在可重复读级别就消除了幻读的可能。

下面来简述下四种隔离级别的概念：

读未提交（Read Uncommitted）：
读未提交，顾名思义，就是可以读到未提交的内容。
因此，在这种隔离级别下，查询是不会加锁的，也由于查询的不加锁，所以这种隔离级别的一致性是最差的，可能会产生“脏读”、“不可重复读”、“幻读”。
如无特殊情况，基本是不会使用这种隔离级别的。

读提交（Read Committed）

读提交，顾名思义，就是只能读到已经提交了的内容。

这是各种系统中最常用的一种隔离级别，也是SQL Server和Oracle的默认隔离级别。这种隔离级别能够有效的避免脏读，但除非在查询中显示的加锁，如：

select * from T where ID=2 lock in share mode;
select * from T where ID=2 for update;

不然，普通的查询是不会加锁的。

那为什么“读提交”同“读未提交”一样，都没有查询加锁，但是却能够避免脏读呢？

这就要说道另一个机制“快照（snapshot）”，而这种既能保证一致性又不加锁的读也被称为“快照读（Snapshot Read）”

假设没有“快照读”，那么当一个更新的事务没有提交时，另一个对更新数据进行查询的事务会因为无法查询而被阻塞，这种情况下，并发能力就相当的差。

而“快照读”就可以完成高并发的查询，不过，“读提交”只能避免“脏读”，并不能避免“不可重复读”和“幻读”。

可重复读(Repeated Read)

可重复读，顾名思义，就是专门针对“不可重复读”这种情况而制定的隔离级别，自然，它就可以有效的避免“不可重复读”。而它也是MySql的默认隔离级别。

在这个级别下，普通的查询同样是使用的“快照读”，但是，和“读提交”不同的是，当事务启动时，就不允许进行“修改操作（Update）”了，而“不可重复读”恰恰是因为两次读取之间进行了数据的修改，因此，“可重复读”能够有效的避免“不可重复读”，但却避免不了“幻读”，因为幻读是由于“插入或者删除操作（Insert or Delete）”而产生的。

串行化（Serializable）

这是数据库最高的隔离级别，这种级别下，事务“串行化顺序执行”，也就是一个一个排队执行。

这种级别下，“脏读”、“不可重复读”、“幻读”都可以被避免，但是执行效率奇差，性能开销也最大，所以基本没人会用。
用表格简述上述内容如下：

那么异常产生了，我们又该如何预防呢？

下面就简单阐述下并发异常的控制技术：

并发控制技术是实现事务隔离性以及不同隔离级别的关键,实现方式有很多,按照其对可能冲突的操作采取的不同策略可以分为乐观并发控制和悲观并发控制两大类。

• **乐观并发控制:**对于并发执行可能冲突的操作,假定其不会真的冲突,允许并发执行,直到真正发生冲突时才去解决冲突,比如让事务回滚。
• **悲观并发控制:**对于并发执行可能冲突的操作,假定其必定发生冲突,通过

• 基于封锁的并发控制

让事务等待(锁)或者中止(时间戳排序)的方式使并行的操作串行执行。
核心思想:对于并发可能冲突的操作,比如读-写,写-读,写-写,通过锁使它们互斥执行。
锁通常分为共享锁和排他锁两种类型

1.共享锁(S):事务T对数据A加共享锁,其他事务只能对A加共享锁但不能加排他锁。
2.排他锁(X):事务T对数据A加排他锁,其他事务对A既不能加共享锁也不能加排他锁
基于锁的并发控制流程:

事务根据自己对数据项进行的操作类型申请相应的锁(读申请共享锁,写申请排他锁)

申请锁的请求被发送给锁管理器。锁管理器根据当前数据项是否已经有锁以及申请的和持有的锁是否冲突决定是否为该请求授予锁。

若锁被授予,则申请锁的事务可以继续执行;若被拒绝,则申请锁的事务将进行等待,直到锁被其他事务释放。

可能出现的问题:

死锁:多个事务持有锁并互相循环等待其他事务的锁导致所有事务都无法继续执行。

饥饿:数据项A一直被加共享锁,导致事务一直无法获取A的排他锁。

对于可能发生冲突的并发操作,锁使它们由并行变为串行执行,是一种悲观的并发控制。

• 基于时间戳的并发控制

核心思想:对于并发可能冲突的操作,基于时间戳排序规则选定某事务继续执行,其他事务回滚。

系统会在每个事务开始时赋予其一个时间戳,这个时间戳可以是系统时钟也可以是一个不断累加的计数器值,当事务回滚时会为其赋予一个新的时间戳,先开始的事务时间戳小于后开始事务的时间戳。

每一个数据项Q有两个时间戳相关的字段:

W-timestamp(Q):成功执行write(Q)的所有事务的最大时间戳
R-timestamp(Q):成功执行read(Q)的所有事务的最大时间戳

时间戳排序规则如下:

假设事务T发出read(Q),T的时间戳为TS
a.若TS(T)<W-timestamp(Q),则T需要读入的Q已被覆盖。此
read操作将被拒绝,T回滚。
b.若TS(T)>=W-timestamp(Q),则执行read操作,同时把
R-timestamp(Q)设置为TS(T)与R-timestamp(Q)中的最大值

假设事务T发出write(Q)
a.若TS(T)<R-timestamp(Q),write操作被拒绝,T回滚。
b.若TS(T)<W-timestamp(Q),则write操作被拒绝,T回滚。
c.其他情况:系统执行write操作,将W-timestamp(Q)设置
为TS(T)。

基于时间戳排序和基于锁实现的本质一样:对于可能冲突的并发操作,以串行的方式取代并发执行,因而它也是一种悲观并发控制。它们的区别主要有两点:

基于锁是让冲突的事务进行等待,而基于时间戳排序是让冲突的事务回滚。
基于锁冲突事务的执行次序是根据它们申请锁的顺序,先申请的先执行;而基于时间戳排序是根据特定的时间戳排序规则。

• 基于有效性检查的并发控制

核心思想:事务对数据的更新首先在自己的工作空间进行,等到要写回数据库时才进行有效性检查,对不符合要求的事务进行回滚。

基于有效性检查的事务执行过程会被分为三个阶段:

读阶段:数据项被读入并保存在事务的局部变量中。所有write操作都是对局部变量进行,并不对数据库进行真正的更新。

有效性检查阶段:对事务进行有效性检查,判断是否可以执行write操作而不违反可串行性。如果失败,则回滚该事务。

写阶段:事务已通过有效性检查,则将临时变量中的结果更新到数据库中。

有效性检查通常也是通过对事务的时间戳进行比较完成的,不过和基于时间戳排序的规则不一样。

该方法允许可能冲突的操作并发执行,因为每个事务操作的都是自己工作空间的局部变量,直到有效性检查阶段发现了冲突才回滚。因而这是一种乐观的并发策略。

• 基于快照隔离的并发控制

快照隔离是多版本并发控制(mvcc)的一种实现方式。

其核心思想是:数据库为每个数据项维护多个版本(快照),每个事务只对属于自己的私有快照进行更新,在事务真正提交前进行有效性检查,使得事务正常提交更新或者失败回滚。

由于快照隔离导致事务看不到其他事务对数据项的更新,为了避免出现丢失更新问题,可以采用以下两种方案避免：

先提交者获胜:对于执行该检查的事务T,判断是否有其他事务已经将更新写入数据库,是则T回滚否则T正常提交。

先更新者获胜:通过锁机制保证第一个获得锁的事务提交其更新,之后试图更新的事务中止。

事务间可能冲突的操作通过数据项的不同版本的快照相互隔离,到真正要写入数据库时才进行冲突检测。因而这也是一种乐观并发控制。

• 关于并发控制技术的总结

以上只是对常见的几种并发控制技术进行了介绍,不涉及特别复杂的原理的讲解。之所以这么做一是要真的把原理和实现细节讲清楚需要涉及的东西太多,篇幅太长,从作者和读者角度而言都不是一件轻松的事,所以只对其实现的核心思想和实现要点进行了简单的介绍,其他部分就一笔带过了。二是并发控制的实现的方式太过多样,基于封锁的实现就有很多变体,mvcc多版本并发控制的实现方式就更是多样,而且很多时候会和其他并发控制方式比如封锁的方式结合起来使用。

• 故障与故障恢复技术

为什么需要故障恢复技术 为什么需要故障恢复技术

数据库运行过程中可能会出现故障,这些故障包括事务故障和系统故障两大类

1. 事务故障:比如非法输入,系统出现死锁,导致事务无法继续执行。
2. 系统故障:比如由于软件漏洞或硬件错误导致系统崩溃或中止。

这些故障可能会对事务和数据库状态造成破坏,因而必须提供一种技术来对各种故障进行恢复,保证数据库一致性,事务的原子性以及持久性。数据库通常以日志的方式记录数据库的操作从而在故障时进行恢复,因而可以称之为日志恢复技术。

• 事务的执行过程以及可能产生的问题

事务的执行过程可以简化如下:

系统会为每个事务开辟一个私有工作区

• 事务读操作将从磁盘中拷贝数据项到工作区中,在执行写操作前所有的更新都作用于工作区中的拷贝.
• 事务的写操作将把数据输出到内存的缓冲区中,等到合适的时间再由缓冲区管理器将数据写入到磁盘。

由于数据库存在立即修改和延迟修改,所以在事务执行过程中可能存在以下情况:

• 在事务提交前出现故障,但是事务对数据库的部分修改已经写入磁盘数据库中。这导致了事务的原子性被破坏。
• 在系统崩溃前事务已经提交,但数据还在内存缓冲区中,没有写入磁盘。系统恢复时将丢失此次已提交的修改。这是对事务持久性的破坏。

• 日志的种类和格式

<T,X,V1,V2>:描述一次数据库写操作,T是执行写操作的事务的唯一标识,X是要写的数据项,V1是数据项的旧值,V2是数据项的新值。

<T,X,V1>:对数据库写操作的撤销操作,将事务T的X数据项恢复为旧值V1。在事务恢复阶段插入。

<T start>: 事务T开始

<T commit>: 事务T提交

<T abort>: 事务T中止

关于日志,有以下两条规则

• 系统在对数据库进行修改前会在日志文件末尾追加相应的日志记录。
• 当一个事务的commit日志记录写入到磁盘成功后,称这个事务已提交,但事务所做的修改可能并未写入磁盘

• 日志恢复的核心思想

• 撤销事务undo:将事务更新的所有数据项恢复为日志中的旧值,事务撤销完毕时将插入一条<T abort>记录。
• 重做事务redo:将事务更新的所有数据项恢复为日志中的新值。

事务正常回滚/因事务故障中止将进行redo
系统从崩溃中恢复时将先进行redo再进行undo。

以下事务将进行undo:日志中只包括<T start>记录,但既不包括<T commit>记录也不包括<T abort>记录.

以下事务将进行redo:日志中包括<T start>记录,也包括<T commit>记录或<T abort>记录。

假设系统从崩溃中恢复时日志记录如下

<T0 start>
<T0,A,1000,950>
<T0,B,2000,2050>
<T0 commit>
<T1 start>
<T1,C,700,600>

由于T0既有start记录又有commit记录,将会对事务T0进行重做,执行相应的redo操作。
由于T1只有start记录,将会对T1进行撤销,执行相应的undo操作,撤销完毕将写入一条abort记录。

- 事务故障中止/正常回滚的恢复流程

• 从后往前扫描日志,对于事务T的每个形如<T,X,V1,V2>的记录,将旧值V1写入数据项X中。
• 往日志中写一个特殊的只读记录<T,X,V1>,表示将数据项恢复成旧值V1, 这是一个只读的补偿记录,不需要根据它进行undo。
• 一旦发现了日志记录,就停止继续扫描,并往日志中写一个 日志记录。

- 系统崩溃时的恢复过程(带检查点)

检查点是形如的特殊的日志记录,L是写入检查点记录时还未提交的事务的集合,系统保证在检查点之前已经提交的事务对数据库的修改已经写入磁盘,不需要进行redo。检查点可以加快恢复的过程。

系统奔溃时的恢复过程分为两个阶段:重做阶段和撤销阶段。

重做阶段:

• 系统从最后一个检查点开始正向的扫描日志,将要重做的事务的列表undo-list设置为检查点日志记录中的L列表。
• 发现<T,X,V1,V2>的更新记录或<T,X,V>的补偿撤销记录,就重做该操作。
• 发现记录,就把T加入到undo-list中。
• 发现或记录,就把T从undo-list中去除。

撤销阶段:

• 系统从尾部开始反向扫描日志
• 发现属于undo-list中的事务的日志记录,就执行undo操作
• 发现undo-list中事务的T的记录,就写入一条记录, 并把T从undo-list中去除。
• undo-list为空,则撤销阶段结束

**总结:**先将日志记录中所有事务的更新按顺序重做一遍,在针对需要撤销的事务按相反的顺序执行其更新操作的撤销操作。
##### 一个系统崩溃恢复的例子

恢复前的日志如下,写入最后一条日志记录后系统崩溃

<T0 start>
<T0,B,2000,2050>
<T2 commit>
<T1 start>
<checkpoint {T0,T1}>   //之前T2已经commit,故不用重做
<T1,C,700,600>
<T1 commit>
<T2 start>
<T2,A,500,400>
<T0,B,2000>
<T0 abort>   //T0回滚完成,插入该记录后系统崩溃

总结

事务是数据库系统进行并发控制的基本单位,是数据库系统进行故障恢复的基本单位,从而也是保持数据库状态一致性的基本单位。ACID是事务的基本特性,数据库系统是通过并发控制技术和日志恢复技术来对事务的ACID进行保证的,从而可以得到如下的关于数据库事务的概念体系结构。

**

参考资料

**
https://www.cnblogs.com/takumicx/p/9998844.html