更新事务

我不是女神ヾ 2022-05-15 04:20 86阅读 0赞

#### 写在前面 ####

> 事务的ACID性质

当系统上进程没有活动的事务的时候，一个事务就可以开始。当事务处于执行状态的时候，他所做的任何更新对于并行用户是不可见的，并且数据读不能被更新。

关于事务的执行有两条语句  
第一条：  
exec sql commit work;

程序员使用这条语句告知系统当前的事务已经完成成功，事务所做的更新在数据库将永久的保存并对并行用户可见。  
第二条：  
exec sql rollback work;

这条语句指出当前的事务执行失败，事务所做的所有修改将被撤销，被修改的数据将恢复大修改之前的版本并对用户可见。

> 事务这个概念是解决大型数据库系统应用过程面临的一系列问题

问题：

*  产生不一致问题。
 *  并发执行的错误。
 *  关于何时更新的数据会变为持久化的不确定性。  
    为了减少磁盘的访问次数，通常将页面存放在内存当中，这意味着对于一条经常需要用到的记录会在内存当中放置很长一段时间，当崩溃发生是我们只能找到已经写在磁盘上的内容。所以似乎只有两种选择：一种是一旦有修改的操作发生就将缓冲的记录写到磁盘上，（如果这样就根本不能通过缓冲的机制减少磁盘的IO操作），另一种就是发生修改的时候不做频繁的写回操作，但是对于每一个记录没有完成磁盘的写操作我们能够相信更新被记录下来了么？

> 为了解决以上的问题 提出了事务的概念

将事务定义为对数据库的一串的读写操作，这些操作组成一个逻辑单位。  
应用程序员决定将怎样的读取和更新操作组成一个事务，接着数据流系统通过提供四个保证来解决上面提到的各种问题。

这四个保证称之为ACID性质：

*  Atomicity 原子性
 *  Consistency 一致性
 *  Isolation 隔离性
 *  Durability 持久性

> 原子性

事务的这一性质保证事务包含的一组更新的操作是原子不可分的。  
也就是这些操作对于数据库要么是全做要么是全不做。  
这一性质在系统崩溃之后任然得到保证，  
一个称为数据库恢复的过程将在系统崩溃之后执行用来恢复或者撤销系统崩溃时处于活动状态的事务对数据库的影响从而保证原子性。这样就可以解决不一致性的问题。

系统对磁盘上任何操作的实际数据做出修改之前都会将关于操作本身的记录信息记录到磁盘上。（增加额外的存储信息保证一致性）发生崩溃之后系统就能够根据这些信息决定是撤销还是程序执行某些事物。

> 一致性

一致性是由事务的另外一个更基本的性质隔离性表示的。

> 隔离性

意味着仅当另个事务不处于并发的状态的时候，也就是他们的操作不是交错的时候，其中一个事务对另一个事务才有影响。  
这一性质的另一种说法就是可串行性。  
系统允许的任何交错的调度等价于某一个串行调度。  
由于性能的原因，我们需要进行交错操作的调度，但是我们也希望这些交错的调度的效果和某一串行调度是一致的。 隔离性就很好的 解决了并发执行导致错误的问题。

通常是对事务加锁保证这一性质的。

> 持久性

当事务发出提交语句之后系统返回到程序逻辑时，必须保证该事务是可恢复的。  
事务产生的影响是持久的。

必须保证只读事务读到的行不包含未提交的事务修改的数据。

> 事务经历

当允许两个或者多个用户对数据库同时执行交错操作的时候就会出现事务的隔离性的要求。  
当调度器发现某些操作在当前顺序当中会破坏隔离性时就会延迟该操作的执行。

应用程序接受用户的请求，事务管理器初始化事务解释调用为事务分配事务号，调度器将所有的调用解释为读写操作通过读写锁的方式保证隔离性。

> 对于一个串行经历而言不会产生不同事务的读写操作交替执行导致的不一致性的问题，那为什么我们要交替执行来自不同的事务的读写操作呢？为什么不严格的串行执行呢？

下面这个方法可以作为调度器在操作上实现事务串行的规则：  
一旦一个事务读写开始，这个事务就是活动的，其他的事务想要进来调度器就会让该事务处于等待知道前面活动的事务完成或者异常中止。如果多个事务在等待就以先来先服务的方式启动下一个。

大多数的数据库不强制事务严格执行串行执行的原因很简单，不同的事务操作交替执行大大的提高了系统的性能，在处理过程当中多个事务的并发可以大大的提高CPU的利用率。这样就提高了整个系统的吞吐量。吞吐量可以以给定的时间完成的事务的数量衡量。

如果两个不同的事务发出的读写操作访问的都是同一个数据对象并且其中至少有一个是写操作另一个可以是写也可以是读操作就说这两个操作是冲突的。  
如果在经历H当中分别属于两个事物的两个操作是冲突操作当其中一个在另一个之前执行那么等价的串行经历当中相应的事务也应该保持相同的先后顺序。

两个读操作中间没有其他的写操作这两个读是不会冲突的。  
但是两个写操作必然会产生冲突，写的结果是最后一个写决定的。  
在不同的对象上的任何操作都是不会冲突的（这样的操作可以直接并行）

R W  
W R  
W W  
这样的组合都会产生冲突

> 丢失更新 脏写

每个事务都是先读某个值再向这个数据写入新的值，没有意识到另外一个事务也在同时对一个数据项进行同样的操作。

> 盲写 ：不需要读操作就进行写

从系统的性能角度出发，严格的串行经历实不可取的。

> 商业数据库系统当中用来保证事务一致性的一个非常著名的锁机制称为两段锁协议 2PL

三条规则规定2PL当中时如何申请锁和释放锁的

*  当事务试图读取某个数据项是发出读操作，调度器解释该操作并且代表该操作第一次向该数据项加读锁，同理写操作的时候加写锁。
 *  在获得某个数据项的锁之前调度器将请求事务处于等待状态直到数据项上没有冲突锁为止。同一个数据项上的两个锁被称为冲突的当且仅当他们为不同的事务并且要求这两个锁至少有一个写锁。
 *  加锁有两个阶段，申请阶段：事务获得要求的锁。释放阶段：事务释放拥有的锁。调度器必须保证一旦释放阶段开始不允许该事务再申请新的锁。两段规则对于通过锁机制来保证经历的可串行化有着重要作用。

> 冲突锁的定义明显就是要保证冲突操作的两个事物是可串行化的。

导致死锁的事务就必须异常中止，异常中止的事务将从经历当中删除，以便结果是可串行化的，因此两段锁原理保证了一个可串行化的经历。出现死锁就将其中一个事务异常中止从经历当中删除，以便结果可以串行化。

> 等待图

调度器在等待图发生变化的一定时间内检测等待图是否有回路如果有就说明出现了死锁，将选择某些事物作为死锁的牺牲品。可以选择终止最年轻的事务或者已完成操作最少的事务等等。在前面的经历结束之后将重启刚才牺牲的事务。

> 加锁定理：遵循二段锁原则的事务操作经历必然是可串行化的。

隔离级别：

任何对于数据的读写曹操都应该先申请该数据的读写锁。  
调度器将一直保留这些获得的锁直到获得的锁能够安全的释放为止。  
二段锁的第三条性质确保一个事务不能在释放一个锁之后又去申请不同的锁，所以必须保留所有已经获得的锁直到没有新的数据访问的操作产生。

然而这样保证很好的串行性的调度对性能有很大的影响。  
在并发的情况下，更多的线程并发进行事务操作，特别是线程特别多，又是对于常用数据的的操作时，对数据的存取就会产生大量的重叠，锁冲突意味着越来越多的事务处于等待状态。产生死锁的次数随之增加，这时终止某些事物随后重启的方式将很大程度的浪费计算机资源。

结果：并发事务增多，导致越来越多的事务由于锁的冲突进入等待。

性能问题不是因为异常中止而又重启带来的，而是CPU从来没有被充分的利用。  
应该是保持足够有效的并发性使得事务的IO重叠使得CPU处于繁忙状态。

所以说需要弱化两段锁的规则降低事务由于冲突的等待，但是我们将不能对事物的隔离性提供强有力的保证有可能产生不一致的结果。

所以语法提供允许在启动事务的SQL语句之前设置隔离级别。

*  Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
 *  Read committed (读已提交)：可避免脏读的发生。
 *  Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
 *  Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。

我们先看看如果不考虑事务的隔离性，会发生的几种问题：

> 脏读

脏读是指在一个事务处理过程里==读取了另一个未提交的事务中的数据==。  
当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。

> 不可重复读

不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。  
例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。  
不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

因为这里是由一个事务只在读取数据的过程当中持有读锁。其他事务可以在该事务两次读操作之间更新数据。

> 幻读

幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。  
　　  
简单的来说：就是读到了其他事务提交的结果，突然多了你之前没看到的数据这就像是幻觉一样。

> 在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)；而在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。

在MySQL数据库中查看当前事务的隔离级别：

select @@tx_isolation;

在MySQL数据库中设置事务的隔离 级别：

set  [glogal | session]  transaction isolation level 隔离级别名称;
    
     set tx_isolation=’隔离级别名称;’

> 短期锁

是指数据项的锁只是在执行相关存取操作的一段时间内保留。由于大多数事务会访问多个数据因此申请短期锁的事务往往不满足两段锁的第三条规则，所以有可能会产生不可串行化的行为。长期锁就是将锁一直保留到事务的提交为止。

> Read uncommitted (读未提交)

无论访问什么数据都不加锁，但是此级别下更新操作是不允许的是只读的所以不会产生脏写。脏读的确可能发生。因为读取操作会忽略其他事务在这些数据上加的锁，因此可能读到为被提交的数据。因为不需要申请任何锁就可以访问数据。

> Read committed (读已提交)

写锁作为长期锁，读锁作为短期锁。