最近有人问我关于隔离级别的问题,因为这东西一般情况是不考虑的,数据库引擎已经都默认帮我们选好了,很少的情况需要人工干预,解释了一会算是忽悠过去了,但是还是觉得说的不清楚,仔细梳理了一下思路,写篇文字,输出一下,大晚上的不能白当误时间啊,怎么着自己要有点收获,所以有了这篇文章。
隔离级别其实就是解决事物的并发问题,如果操作系统课程学的好,就会很容易get到隔离级别的原理。并发执行的事务由于系统调度策略,其过程如果不加控制就会出现读写的不一致问题。当然也不是所有的并发事务都有这种问题,如果事务都是只读的那么就没有问题了,只有并发的读写事务才会需要隔离。
我们简单的聊一下并发的事务出现不一致的根源,对于主流服务器的操作系统,都是按照时间片轮转的方式调度线程的,数据库是一个程序,而运行中的事务(SQL代码)就是一个线程,一个线程被调度的时候分配一个时间片,到点就换另一个线程,不管前一个线程是否执行完成,这种调度策略决定了各个线程的执行顺序、时间都是不固定的,如果没有线程控制,那么并发执行的线程结果就是不可预料的。
为了解决并发事务的一致性,SQL标准提出了四种隔离级别:
1、未提交读(read uncommitted)
这种读也叫脏读,通常一个事务结束的时候会有一个提交的操作,这个提交就代表了这个事务完成了所有的操作,数据库这时候就会把这个事务的一系列操作持久化。如果一个事务没有提交其操作,就代表这个事务所做的所有的修改都不是最终的状态。而未提交读这种隔离级别可以让一个事务读取另一个事务修改过但是没有提交的数据。
我们考虑以下两个事务:
T1:
update user set age=10 where name='amand'
...一系列操作
update user set age=20 where name='amand'
T2
select age from user where name='amand'
T1这个事务进行了2个操作,第一次把amand的age改为10,第二次改为20
T2这个事务读取amand的age
先看第一种情况:
事务T1的两个操作都执行完成,T2再执行,这时候T2获得的是T1的最终执行结果,正确。
![](https://img.haomeiwen.com/i13591648/078dcb420b0f5fa2.jpg)
在看第二种情况:
如果T1、T2穿插着执行,这时候T2获得的就是T1的中间结果,T2获得的数据就是错的。而造成这个问题的原因就是T2读取了T1未提交的结果。
![](https://img.haomeiwen.com/i13591648/95f0f5772d2a7017.jpg)
2、提交读(read committed)
提交读指的是,事务只能读取其他事务提交后的修改结果,如果一个修改结果没有被提交,那么这个修改的数据是无法被其他事务读取的。
我们考虑以下两个事务:
T1:
update user set age=10 where name='amand'
...一系列操作
update user set age=20 where name='amand'
T2
select age from user where name='amand'
...一系列操作
select age from user where name='amand'
首先我们定义,amand的age最开始的值为60
T1这个事务进行了2个操作,第一次把amand的age改为10,第二次改为20
T2这个事务读取amand的age2次
第一种情况:
可以看到,T1和T2虽然穿插着执行,但是T2两次读取都是一样的,即便T1一个操作把age改成了10,但是这个操作没有提交,所以T2是不可见的。
![](https://img.haomeiwen.com/i13591648/9ab557e6af98f6b2.jpg)
再看第二种情况:
我们发现,T2这个事务读取的数据两次不一致了,虽然数据库按照隔离策略使得T2看到的数据都是T1提交后的数据,但T2的两次读取结果却不一样,这个问题就是无法重复读问题。造成这个问题的原因就是这种隔离级别事务之间是独立的,相互之间无法知道对方的状态,就是说T1进行数据更改,T2并不知道,如果T1在更改的数据之前告诉T2一声,那么T2就知道数据要修改了,我需要等T1修改完再查询,那么这种情况就不会出现。
![](https://img.haomeiwen.com/i13591648/1b005580001b47f6.jpg)
3、可重复读 repeatable read
可重复读就是说,一个事务在其生命周期的读操作是一致的,不会出现两次相同条件的读取操作返回两个不同的结果。
先看第一种情况:
可以看到,T2第一次读取的时候,就给amand加上了行级锁,当T1执行amand的修改的时候会遇到行级锁,这时候就只能等待锁释放才可以继续进行,这时的T1事务进程就是被阻塞的,等到T2事务完成,释放行级锁,T1才能执行。
![](https://img.haomeiwen.com/i13591648/f076bff1a6c07d67.jpg)
可重复读虽然加了行级锁,但会出现幻读的问题,让我们看一下下面的例子:
T1、T2穿插执行,T2获得第一次查询结果后,T1插入了一条名字也为amand的记录,这个amand的age为40,这时user表中就存在2条名字为amand的记录了,因为是新增的行,所以T2没有遇到行级锁,这个数据是可以插入的,那么当T2再次读取的时候就会多了1条数据,这时候两次读取又不一致了(是不是很抓狂,哈哈)。这种情况出现的原因就是没有对潜在满足T2的查询条件都进行锁定。目前主流的数据库对这种情况使用的是MVCC技术来解决,不同的厂家实现的方式不同,MySQL的innodb是通过给每个行加两个隐藏的列:创建版本号列、过期版本号列来实现,具体实现的原理本文不展开,待以后有时间给大家补上。
![](https://img.haomeiwen.com/i13591648/e13dfa4157a312f3.jpg)
4、串行化读 serializable
这种隔离级别可以解决上述三种隔离级别出现的问题,简单讲就是排队执行,一个一个来,这样就不存在事务之间相互干扰问题了,但是这个级别效率不高,因为事务之间没法并发执行了。
![](https://img.haomeiwen.com/i13591648/0662114cc1f27636.jpg)
网友评论