本篇文章带大家了解一下MySQL中的事务隔离,介绍一下事务的特性、隔离级别、事务启动的方式等,希望对大家有所帮助!
事务就是要保证一组数据库操作,要么全部成功,要么全部失败。在MySQL中,事务支持是在引擎层实现的,但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务。【相关推荐:mysql教程(视频)】
1.当数据库上有多个事务同时执行的时候,就可能出现脏读、不可重复读、幻读的问题
2.事务的隔离级别包括:读未提交、读提交、可重复读和串行化
安全性依次提交,性能依次降低
3.假设数据表T中只有一列,其中一行的值为1
create table T(c int) engine=InnoDB; insert into T(c) values(1);
下面是按照时间顺序执行两个事务的行为:
在实现上,数据库里面会创建一个视图,访问的时候以视图的逻辑结果为准。在可重复读隔离级别下,这个视图是在事务启动时创建的,整个事务存在期间都用这个视图。在读提交隔离级别下,这个视图是在每个SQL语句开始执行的时候创建的。读未提交隔离级别下直接返回记录上的最新值,没有视图概念;而串行化隔离级别下直接用加锁的方式来避免并行访问
在MySQL中,每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值,通过回滚操作,都可以得到前一个状态的值
假设一个值从1被按顺序改成了2、3、4,在回滚日志里面就会有类似下面的记录
当前值是4,但是在查询这条记录的时候,不同时刻启动的事务会有不同的read-view。如图中看到的,在视图A、B、C里面,这一个记录的值分别是1、2、4,同一条记录在系统中可以存在多个版本,就是数据库的多版本并发控制(MVCC)。对于read-viewA,要得到1,就必须将当前值一次执行图中所有的回滚操作得到
即使现在有另外一个事务正在将4改成5,这个事务跟read-view A、B、C对应的事务是不会冲突的
系统会判断,当没有事务再需要用到这些回滚日志时,回滚日志会被删除
MySQL的事务启动方式有以下几种:
建议使用set autocommit=1,通过显示语句的方式来启动事务
可以在information_schema库中的innodb_trx这个表中查询长事务,如下语句查询持续时间超过60s的事务
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
下面是一个只有两行的表的初始化语句:
mysql> CREATE TABLE `t` ( `id` int(11) NOT NULL, `k` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; insert into t(id, k) values(1,1),(2,2);
事务A、B、C的执行流程如下,采用可重复读隔离级别
begin/start transaction命令:不是一个事务的起点,在执行到它们之后的第一个操作InnoDB表的语句,事务才真正启动,一致性视图是在执行第一个快照读语句时创建的
start transaction with consistent snapshot命令:马上启动一个事务,一致性视图是在执行这条命令时创建的
按照上图的流程执行,事务B查到的k的值是3,而事务A查到的k的值是1
在可重复读隔离级别下,事务启动的时候拍了个快照。这个快照是基于整个库的,那么这个快照是如何实现的?
InnoDB里面每个事务有一个唯一的事务ID,叫做transaction id。它在事务开始的时候向InnoDB的事务系统申请,是按申请顺序严格递增的
每行数据也都是有多个版本的。每次事务更新数据的时候,都会生成一个新的数据版本,并且把transaction id赋值给这个数据版本的事务ID,记作row trx_id。同时,旧的数据版本要保留,并且在新的数据版本中,能够有信息可以直接拿到它。也就是说,数据表中的一行记录,其实可能有多个版本,每个版本有自己的row trx_id
下图是一个记录被多个事务连续更新后的状态:
语句更新生成的undo log(回滚日志)就是上图中的是哪个虚线箭头,而V1、V2、V3并不是物理上真实存在的,而是每次需要的时候根据当前版本和undo log计算出来的。比如,需要V2的时候,就是通过V4依次执行U3、U2算出来的
按照可重复读的定义,一个事务启动的时候,能够看到所以已经提交的事务结果。但是之后,这个事务执行期间,其他事务的更新对它不可见。在实现上,InnoDB为每个事务构造了一个数组,用来保存这个事务启动瞬间,当前在启动了但还没提交的所有事务ID。数组里面事务ID的最小值记为低水位,当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组和高水位就组成了当前事务的一致性视图。而数据的可见性规则,就是基于数据的row trx_id和这个一致性视图的对比结果得到的
这个视图数组把所有的row trx_id分成了几种不同的情况
对于当前事务的启动瞬间来说,一个数据版本的row trx_id,有以下几种可能:
1)如果落在绿色部分,表示这个版本是已提交的事务或者是当前事务自己生成的,这个数据是可见的
2)如果落在红色部分,表示这个版本是由将来启动的事务生成的,肯定不可见
3)如果落在黄色部分,那就包括两种情况
InnoDB利用了所有数据都有多个版本的这个特性,实现了秒级创建快照的能力
假设:
1.事务A开始时,系统里面只有一个活跃事务ID是99
2.事务A、B、C的版本号分别是100、101、102
3.三个事务开始前,(1,1)这一行数据的row trx_id是90
这样,事务A的是数组就是[99,100],事务B的视图数组是[99,100,101],事务C的视图数组是[99,100,101,102]
从上图中可以看到,第一个有效更新是事务C,从数据从(1,1)改成了(1,2)。这时候,这个数据的最新版本的row trx_id是102,而90这个版本已经成为了历史版本
第二个有效更新是事务B,把数据从(1,2)改成了(1,3)。这时候,这个数据的最新版本是101,而102又成为了历史版本
在事务A查询的时候,其实事务B还没提交,但是它生成的(1,3)这个版本已经变成当前版本了。但这个版本对事务A必须是不可见的,否则就变成脏读了
现在事务A要读数据了,它的视图数组是[99,100]。读数据都是从当前版本读起的。所以,事务A查询语句的读数据流程是这样的:
虽然期间这一行数据被修改过,但是事务A不论在什么时候查询,看到这行数据的结果都是一致的,我们称之为一致性读
一个数据版本,对于一个事务视图来说,除了自己的更新总是可见以外,有三种情况:
事务A的查询语句的视图数组是在事务A启动的时候生成的,这时候:
事务B要去更新数据的时候,就不能再在历史版本上更新了,否则事务C的更新就丢失了。因此,事务B此时的set k=k+1是在(1,2)的基础上进行的操作
更新数据都是先读后写的,而这个读,只能读当前的值,称为当前读。除了update语句外,select语句如果加锁,也是当前读
假设事务C不是马上提交的,而是变成了下面的事务C’,会怎么样?
上图中,事务C更新后没有马上提交,在它提交前,事务B的更新语句先发起了。虽然事务C还没提交,但是(1,2)这个版本也已经生成了,并且是当前的最新版本
这时候涉及到了两阶段锁协议,事务C没提交,也就是说(1,2)这个版本上的写锁还没释放。而事务B是当前读,必须要读最新版本,而且必须加锁,因此就被锁住了,必须等到事务C释放这个锁,才能继续它的当前读
可重复读的核心就是一致性读;而事务更新数据的时候,只能用当前读。如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待
而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:
更多编程相关知识,请访问:编程视频!!
以上是带你聊聊MySQL中的事务隔离的详细内容。更多信息请关注PHP中文网其他相关文章!