欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

SQL中的事务ACID

程序员文章站 2022-03-26 23:13:51
概述: 事务是由一系列语句构成的逻辑工作单元。事务和存储过程等批处理有一定程度上的相似之处, 通常都是为了完成一定业务逻辑而将一条或者多条语句“封装”起来,使它们与其他语句之间出现一个逻辑上的边界,并形成相对独立的一个工作单元。 当使用事务修改多个数据表时,如果在处理的过程中出现了某种错误,例如系统 ......

概述:

事务是由一系列语句构成的逻辑工作单元。事务和存储过程等批处理有一定程度上的相似之处,

通常都是为了完成一定业务逻辑而将一条或者多条语句“封装”起来,使它们与其他语句之间出现一个逻辑上的边界,并形成相对独立的一个工作单元。

当使用事务修改多个数据表时,如果在处理的过程中出现了某种错误,例如系统死机或突然断电等情况,则返回结果是数据全部没有被保存。

因为事务处理的结果只有两种:一种是在事务处理的过程中,如果发生了某种错误则整个事务全部回滚,使所有对数据的修改全部撤销,事务对数据库的操作是单步执行的,当遇到错误时可以随时回滚;

另一种是如果没有发生任何错误且每一步的执行都成功,则整个事务全部被提交。从而可以看出,有效地使用事务不但可以提高数据的安全性,还可以增强数据的处理效率。

mysql 事务主要用于处理操作量大,复杂度高的数据。比如说,在人员管理系统中,你删除一个人员,你既需要删除人员的基本资料,也要删除和该人员相关的信息,如信箱,文章等等,这样,这些数据库操作语句就构成一个事务!

  • 在 mysql 中只有使用了 innodb 数据库引擎的数据库或表才支持事务。
  • 事务处理可以用来维护数据库的完整性,保证成批的 sql 语句要么全部执行,要么全部不执行。
  • 事务用来管理 insert,update,delete 语句

事务包含四种重要的属性,被统称为acid(指数据库事务正确执行的四个基本要素的缩写)

包含:原子性(atomicity)一致性(consistency)隔离性(isolation)持久性(durability)

一个支持事务(transaction)的数据库,必须要具有这四种特性。

否则在事务过程(transaction processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求,一个事务必须通过acid。

 

1、原子性:

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

事务在执行过程中发生错误,会被回滚(rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。

 

2、一致性:

一个事务可以封装状态改变(除非它是一个只读的)。

事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少。

也就是说:如果事务是并发多个,系统也必须如同串行事务一样操作。

其主要特征是保护性和不变性(preserving an invariant),以转账案例为例,假设有五个账户,每个账户余额是100元,那么五个账户总额是500元

如果在这个5个账户之间同时发生多个转账,无论并发多少个,比如在a与b账户之间转账5元,在c与d账户之间转账10元,在b与e之间转账15元,五个账户总额也应该还是500元,这就是保护性和不变性。

 

3、隔离性

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

如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。

 

4、持久性

在事务提交完成以后,该事务对数据库所做的更改便持久的保存在数据库之中,永久保存下来,并不会被回滚。

 

5、说明

由于一项操作通常会包含许多子操作,而这些子操作可能会因为硬件的损坏或其他因素产生问题,要正确实现acid并不容易。

acid建议数据库将所有需要更新以及修改的资料一次操作完毕,但实际上并不可行。

目前主要有两种方式实现acid:第一种是write ahead logging,也就是日志式的方式(现代数据库均基于这种方式)。第二种是shadow paging

相对于wal(write ahead logging)技术,shadow paging技术实现起来比较简单,消除了写日志记录的开销恢复的速度也快(不需要redo和undo)。

shadow paging的缺点就是事务提交时要输出多个块,这使得提交的开销很大,而且以块为单位,很难应用到允许多个事务并发执行的情况——这是它致命的缺点。

wal 的中心思想是对数据文件 的修改(它们是表和索引的载体)必须是只能发生在这些修改已经 记录了日志之后,也就是说,在日志记录冲刷到永久存储器之后。

如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下,

我们可以用日志来恢复数据库:任何尚未附加到数据页的记录都将先从日志记录中重做(这叫向前滚动恢复,也叫做 redo) 然后那些未提交的事务做的修改将被从数据页中删除 (这叫向后滚动恢复 - undo)。