光輝歲月

导航

 

  直接起飞~

 

  什么是事务?

    事务由一组SQL语句组成的逻辑处理单元。

 

  事务特性?

    原子性(Atomicity) :事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。(整体上是一个原子,不可拆分)

    一致性(Consistent) :在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规 则都必须应用于事务的修改,以保持数据的完整性。(数据上来说,保证数据在事务内的准确性)

    隔离性(Isolation) :数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独 立”环境执行。

              这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。(事务与事务之间是分隔的,不可见的)

    持久性(Durable) :事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。(所有的事务操作在提交之后都会持久化到磁盘上面)

 

  1.并发情况下,mysql事务会出现的问题

    脏写(Lost Update):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题。

      (最后事务的更新覆盖了由其他事务所做的更新)

    脏读(Dirty Reads):一个事务正在对一条记录做修改,在这个事务完成并提交前,这条记录的数据就处于不一致的状态;

      这时,另一个事务也来读取同一条记录,如果不加控制,第二个事务读取了这些“脏”数据,并据此作进一步的 处理,

      就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。(A事务读到了B事务修改了,但是还未提交的数据不符合隔离性)

    幻读(Phantom Reads):一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数 据,

      这种现象就称为“幻读”。(A事务读取到了B事务提交的新增数据,不符合隔离性)

    不可重复读(Non-Repeatable Reads)一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,

      却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。(事务内读取到的相同记录值一直在变动,不利于代码编写,不符合隔离性)

    

 

 

  2.事务隔离级别

  Mysql默认的事务隔离级别是可重复读,用Spring开发程序时,如果不设置隔离级别默认用Mysql设置的隔 离级别,如果Spring设置了就用已经设置的隔离级别。

 

  

隔离级别 脏读 不可重复读 幻读
读未提交(read uncommitted) 可能 可能 可能
读已提交(read committed) 不可能 可能 可能
可重复读(repeatable read) 不可能 不可能 可能
串行化(serializable) 不可能 不可能 不可能

     

  数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度 上“串行化”进行,这显然与“并发”是矛盾的。

 

 

  我们先来看脏写

    数据库使用本地user_bd,里面有一张test表:

 

   这个时候我们在开一个客户端:

  

 

   给两个客户端开启事务:

 

   我们假设左边的事务叫A事务,右边为B事务;后面都这么叫。

 

  这个时候,我们B事务去更改张三的钱(扣减100):

  

 

  把B事务提交了,然后A事务再去更改张三的钱(假设我们没有上帝视角,不知道其他事务已经更改了money,扣减200,改为800):

  

 

   实际上数据库张三的钱被更改成了800;但是我们要的是张三的钱一共扣减300,应该为700;上面情况就是脏写情况。(可以更改的时候写成money=money-100)

 

 

  2.1读未提交

    设置两个客户端隔离级别为读未提交(set tx_isolation='read-uncommitted';):

  

   开启A事务和B事务,我们在B事务对张三的钱进行更改,再用A事务去查询:

 

   我们可以看到,A事务读取到了B事务修改,但是没有提交的数据(脏读情况)。

   

  B事务继续更改张三的钱,然后A事务去查询张三:

 

   张三的钱一直在变动(不可重复读情况)。

 

  我们在看一下存在幻读的情况吗?B事务插入一条数据,然后A事务再去读取,看下是否能够读取到B事务新差人的数据:

 

   A事务一样查到了B事务新增但是还未提交的数据(幻读情况)。

 

  这里求证了上面表格中读已提交的对于各种并发问题下是否解决。

 

 

  2.2读已提交

  设置两个客户端隔离级别为读已提交(set tx_isolation='read-committed';),并且开启事务A和事务B:

 

 

   我们先来看一下脏读解决了没,B事务更改张三的钱,我们看下A事务读取到的是什么值:

 

   很显然,事务A并没有读取到B事务修改还未提交的数据,读已提交解决了脏读问题;

 

  那么我们继续来看是否解决了不可重复读问题,这个时候我们把B事务提交了,我们再来看下A事务读取到的是什么:

 

  A事务读取的money值在变动,显然是没有解决不可重复读的问题;

 

  那么再看下是否解决了幻读问题呢,B事务开启,然后插入一条数据,A事务去读取:

 

   A事务读取到了B事务新增的数据,显然读已提交并未解决幻读的问题;

 

 

  2.3可重复读

  设置两个客户端隔离级别为可重复读(set tx_isolation='read-committed';),并且开启事务A和事务B:

 

   我们先来看可重复读解决脏读问题了没,B事务去修改张三的值,然后看A事务读取到的是什么:

 

   很显然,A事务并没有读取到B事务修改但是未提交的值,可重复读解决了脏读问题;

 

  继续来看是否解决了不可重复读问题,我们把B事务提交了,这个时候数据库张三的真实值为700,我们在来看A事务读取的是什么:

 

   可以看到,A事务读取到的张三的值一直是900,可重复读解决了不可重复读问题;

 

  我们继续来看幻读问题,我们在把B事务开启,然后在A事务查询是否能找到B事务提交的新增数据:

 

   A事务读取到了B事务新增的数据,可重复读并未解决幻读问题。

 

  问题1:可重复读情况下如何解决幻读问题?

    我们可以加上一共间隙锁(锁的就是两个值之间的空隙);

  我们给test表在插入一条数据:

 

 

   然后开启事务A和事务B:

 

 

  事务A去做一个间隙更改:

 

 

   在往B事务插入数据看看,会是什么情况?

 

 

   B事务直接在等待A事务释放锁了,B事务才会插入成功,解决了幻读的情况。如果A事务没有释放锁,B事务就会插入失败:

 

 

 

 

  

  2.4串行化

  设置两个客户端隔离级别为串行化(set tx_isolation='serializable';),并且开启事务A和事务B:

 

 

   先来看脏读的问题,B事务先去更改张三的钱,A事务去查询:

 

   A事务在等待B事务锁释放了,并没有查询出数据,解决了脏读问题;

 

 

  继续来看不可重复读的问题,我们把B事务提交了,然后看A事务张三是多少钱:

 

   然后B事务窗口去更改张三的钱,在看A事务读取到张三的钱是多少:

  

 

   B事务在等待A事务的锁,并没有修改成功,解决了不可重复读问题;

 

  幻读就不看了,上面例子可以看出,在串行化的隔离级别下,只要事务开启了,对数据不管是查询还是其他操作,都会对那条数据加锁,其他事务想去操作这条数据必须等待其他事务锁释放才能操作

 

 

  3.MVCC(Multi-Version Concurrency Control)多版本并发控制机制

  这次开3个窗口,A,B,C事务,隔离级别为默认的可重复读,进行如下操作:

 

 

 

 

 

   这个时候在开D窗口,开启事务D(注意,事务id在只读的情况是是不会分配给当前事务的,我们这个D窗口只用来查询):

 

 

 

  3.1undo日志版本链与read-view机制详解

  undo日志版本链:undo日志版本链是指一行数据被多个事务依次修改过后,在每个事务修改完后,Mysql会保留修改前的数据undo回滚 日志,并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链。(如下图所示):

 

 

  read-view(一致性视图):视图由执行查询时所有未提交事 务id数组(数组里最小的id为min_id)和已创建的最大事务id(max_id)组成;

 

  上面mvcc开头操作,3个事务,4925为最小的未提交事务id,4926为未提交事务,最大事务id为4929。所以上面操作的read-view为([4925,4926],4929);

 

 

  undo版本链对比规则:

    1. 如果 row 的 trx_id 落在( trx_id<min_id ),表示这个版本是已提交的事务生成的,这个数据是可见的;

    2.如果 row的trx_id落在(trx_id>max_id ),表示这个版本是由将来启动的事务生成的,是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的);

    3. 如果 row 的 trx_id 落在(min_id <=trx_id<= max_id),那就包括两种情况

       a. 若 row 的 trx_id 在视图数组中,表示这个版本是由还没提交的事务生成的,不可见,若 row 的 trx_id 就是当前 自己的事务是可见的;

       b. 若 row 的 trx_id 不在视图数组中,表示这个版本是已经提交了的事务生成的,可见。

    4.对于删除的情况可以认为是update的特殊情况,会将版本链上最新的数据复制一份,然后将trx_id修改成删除操作的 trx_id,同时在该条记录的头信息(record header)里的(deleted_flag)标记位写上true,来表示当前记录已经被 删除,在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true,意味着记录已被删除,则不返回数 据。

 

  好了,开始D窗口操作:

 

 

 

 

   查询到的张三数据是800;我们通过undo日志+read-view来分析:

 

   接下来,我们对A事务进行操作:

 

 

   然后更新undo版本:

 

 

   再用D窗口去查询张三:

 

 

  通过版本日志分析:

    1:先找最新的记录,事务id为4925(落在数组中),属于第三种情况,然后在看4925并未提交,所以属于第三种的a情况,所以,最新的这条数据是不可见的;

    2:再找下一条(money为700),事务id也是4925(落在数组中),跟第一种情况是一样的,不在过多赘述;

    3:在找下一条(money为800),事务id为4929(不在数组中,并且==max_id),属于第三种情况,再看4929是已经提交了的事务,所以这是第三种的b情况,所以money=800是可见的;

 

 

  这个时候把A事务提交了:

 

 

 

   然后用B事务去更改张三的值:

 

 

 

   更新undo日志版本:

 

   我们再用D窗口去查询张三:

 

  通过版本日志分析:

    1:先找最新的记录,事务id为4926(落在数组中),属于第三种情况,然后在看4926并未提交,所以属于第三种的a情况,所以,最新的这条数据是不可见的;

    2:再找下一条(money为900),事务id也是4926(落在数组中),跟第一种情况是一样的,不在过多赘述;

    3:在找下一条(money为600),事务id为4925(落在数组中,并且==min_id),属于第三种情况,再看4925是已经提交了的事务,所以这是第三种的b情况,所以money=600是可见的;

 

  问题2:可重复读隔离级别是怎么实现的?

    基于多版本并发控制,mvcc实现;低层为undo版本日志+一致性试图(read-view);

      那么为什么可重复读情况下一直是读取重复的值呢?

    我们根据undo日志版本想一想就知道了,当前开启的事务去做查询,产生了一致性试图;在后面开启的事务都是大于当前事务id的;对于当前事务来说,是属于大于最大事务id的情况(未来的事务),属于版本判断第二种情况,所以后面的事务无论做出什么修改,我这个值一直是保持这个值。

 

  问题3:读已提交呢?

    读已提交隔离级别下,每次查询都会生成新的一致性试图,所以每次读取的都是数据库最新的数据(阅读者自行推演);

 

posted on 2020-08-15 12:02  光輝歲月  阅读(375)  评论(0编辑  收藏  举报