事务的调度和隔离性级别

事务的调度

一个事务的执行就是一组指令的序列

一组事务的执行的顺序我们可以成为调度

比如限制性事务1，再执行事务2，这种执行顺序就是一种调度

放过来先执行事务2，再执行事务1，这又是一种调度

但是为了更好的事务并发，调度可以渗透到让单个事务中个部分配合执行

比如先执行事务1中的A部分，再执行事务2中的C部分，然后再执行事务1中的B，事务2中的D

这也是调度，数据库合理安排调度，保证并发事务之间的隔离性和一致性

最后要达到的目标是并发事务实现可串行化调度

也就是说，让并发的事务从结果上看起来像串行一样一致

 

 

冲突指令

如果属于不同事务的两个指令对统一数据项进行了操作

任意一个为write指令，那么这两个指令就是冲突的

冲突指的是交换这两个指令的顺序就可能造成不一致性

冲突等价

非冲突指令交换顺序不影响事务的一致性

在众多指令中进行非冲突指令的顺序调换前后的调度是冲突等价的

冲突可串行化

一个调度s与串行调度冲突等价那就称冲突S为冲突可串行化的

如何判断一个调度是否冲突可串行化

也就是保证一个调度是否与串行调度冲突等价

用图论的知识可以判断

 

 

事务的隔离性实现原理

事务隔离性依靠数据库的并发控制机制来实现

而并发控制机制主要考锁和时间戳来实现

锁

共享锁

是对数据项读的一种锁

多个事务可以同时持有一个数据项的共享锁

排它锁

是对数据项写的一种锁

只有任何锁都没有的数据项才能有排它锁

时间戳

共有三种时间戳

事务时间戳

通常是事务开始的时间

数据项读戳

记录最近读数据项的事务的时间戳

数据写戳

记录最近写数据项的事务的时间戳

作用

处理访问冲突的情况

比如多个事务读的时候，按照时间戳的大小进行读

当一个事务访问不了数据项的时候

中止这个事务并且更新事务的时间戳重新开始执行

 

事务的隔离性级别

来由

来由如果研究要求调度的可串行化，那么支持的并发量将会非常低

适当放宽可串行化的标准，采取不那么一致性的调度能得到很好的并发量

不同级别一致性的程度划分除了事务的隔离性级别

可串行化级别

通常保证可串行化调度

说通常是因为某些数据库允许某些情况下非可串行化调度

可重复读

只允许读取已经提交了的数据

而且一个事务两次读取中不允许其他事物更新该数据项

被其他事物更新了之后前后两次读取的数据项值不一样

再简单点说就是不允许一个事务两次读过程中另一个事务写

因为写是更新必须的，光读不算更新

已提交读

只允许读取已经提交的

但不要求可重复读

也就是不要求两次读之间不能被其他事务写

但是可以读

未提交读

允许读未提交的数据

用处

如果有时候想提高系统的性能可以考虑研究下一个业务逻辑

然后选择更低级别的隔离性级别

判断标准是这种理论上的不一致可能在现实中影响不大或者发生概率很低

 

举例

比如航班选择系统中，如果一个用户选择的行程中有多个航班转机

系统允许个飞机，用户都能选自己想要的座位，这是很人性化的

从价加载各飞机各个空余座位信息到用户选好各个飞机的座位这是一整个事务

我们允许两个用户同并发执行这类事务，很可能一个选好了之后被告知

刚刚选的已经没坐了，这在我们看起来很好理解

但是这显然不满足已提交读，因为一个用户还没提交事务的时候

各个用户可以随便进来读

如果我们要求严格已提交读的话，那很可能有些有选择困难症的用户一直挑选

其他的用户就根本没法选座位

注意

所有隔离性级别都不允许脏写

也就是不允许一个事务执行了写之后还没提交或者中止的时候

另一个事务进行了写

即使是未提交读，你的确可以读，但是不能乱写

如果未提交的事务执行了写，未提交读就不能写

但是未提交读没有写，你还是可以读的

多数数据库系统的默认隔离性级别是已提交读