(教妹学数据库系统)(十一)并发控制

hello大家好,好久不见!今天我们继续学习《教妹学数据库系统》。教妹学数据库,没见过这么酷炫的标题吧?“语不惊人死不休”,没错,标题就是这么酷炫。

我的妹妹小埋18岁,校园中女神一般的存在,成绩优异体育万能,个性温柔正直善良。然而,只有我知道,众人眼中光芒万丈的小埋,在过去是一个披着仓鼠斗篷,满地打滚,除了吃就是睡和玩的超级宅女。而这一切的转变,是从那一天晚上开始的。

从此之后,小埋经常让我帮她辅导功课。今天她想了解数据库系统中的并发控制。本篇教程通过我与小埋的对话的方式来谈一谈并发控制

事务

事务(transaction)是在数据库上执行的一个或多个操作构成的序列,用来完成数据库系统的高级功能。
在这里插入图片描述

SQL事务语句

  1. 事务启动(start):BEGIN;

  2. 事务提交(commit):COMMIT;
    将事务对数据库的修改持久地写到数据库中

  3. 事务中止(abort):ROLLBACK;

  • 将事务对数据库的修改全部撤销(undo),就像事务从未执行过

  • 事务可以中止自己,也可以被DBMS中止

事务的ACID性质(TheACIDProperties)

原子性(Atomicity): “allornothing”

  1. 事务的操作要么全部执行,要么一个也不执行

  2. 事务的执行只有两种结局

  • 执行完所有操作后提交⇒不破坏原子性
  • 执行了部分操作后中止⇒破坏原子性
  1. DBMS保证事务的原子性

中止事务(abortedtxn)执行过的操作必须撤销(undo)

一致性(Consistency): “itlookscorrecttome”

如果事务的程序正确,并且事务启动时数据库处于一致状态(consistentstate),则事务结束时数据库仍处于一致状态

  • 用户(user)保证事务的一致性(别写错程序)

隔离性(Isolation):“asifalone”

一个事务的执行不受其他事务的干扰

多个事务的执行有2种方式

  • 串行执行(serial execution) ⇒ 不破坏隔离性

  • 交叉执行(interleaving execution) ⇒ 可能破坏隔离性

DBMS保证事务的隔离性

  • 并发控制(concurrencycontrol):确定多个事务的操作的正确交叉执行顺序

持久性(Durability):“survivefailures”

  1. 事务一旦提交,它对数据库的修改一定全部持久地写到数据库中

  2. 故障(failure)导致事务对数据库的修改有4种结果

  • 提交事务的修改已全部持久存储 ⇒不破坏持久性
  • 提交事务的修改仅部分持久存储 ⇒破坏持久性
  • 中止事务的修改有些已持久存储 ⇒破坏持久性
  • 中止事务的修改未持久存储 ⇒不破坏持久性
  1. DBMS保证事务的持久性
  • 重做(redo)提交事务对数据库的修改
  • 撤销(undo)中止事务对数据库的修改

并发控制

基本概念

  1. 数据库(database):固定的数据对象集合
  • 数据对象是个抽象概念,可以是属性值、元组、页、关系或数据库
  • 数据对象又称数据库元素(databaseelement)
  • 我们先不考虑数据的插入和删除
  1. 事务(transaction):数据库对象的读/写操作序列
  • 事务可以在数据库上进行很多操作,但DBMS只关心事务对数据对象的读/写操作

调度(Schedules)

调度(schedule)是一个或多个事务的重要操作的序列
在这里插入图片描述

串行调度(SerialSchedules)

如果一个调度中不同事务的操作没有交叉(interleave),则该调度是串行调度(serial schedule)。

非串行调度(NonserialSchedules)

不是串行调度的调度称为非串行调度(nonserial schedule)。

调度的正确性(CorrectnessofSchedules)

每个事务孤立执行(executedinisolation),都会将数据库从一种一致性状态(consistent state)变为另一种一致性状态。
在这里插入图片描述
任意串行调度都能保持数据库的一致性
在这里插入图片描述
非串行调度可能会破坏数据库的一致性
在这里插入图片描述

异常(Anomalies)

非串行调度会导致事务的异常行为(anomalybehavior),从而破坏数据库的一致性

脏写(DirtyWrites)

T1提交之前,T1写入的值已被T2覆盖。
在这里插入图片描述

脏读(Dirty Reads)

在这里插入图片描述

不可重复读(UnrepeatableReads)

  • T2更改了已被T1读取的A的值,并且T2提交。

  • 如果T1再次尝试读取该值A,T1也会得到不同结果,即使T1没有修改A值。
    在这里插入图片描述

幻读(Phantoms)

等价调度(Equivalent Schedules)

如果两个调度在任意数据库实例上的效果都相同,则等价(equivalent)。
在这里插入图片描述

可串行化调度(Serializable Schedules)

如果一个调度等价于某串行调度,则该调度是可串行化调度(serializableschedule)
在这里插入图片描述

优点

在这里插入图片描述

缺点

  1. 可串行化调度的并发度低

  2. 在某些场景下,并发事务不需要严格隔离

  • 一个事务对部分对象的修改可以暴露(expose)给对其他并发事务

  • 弱隔离级别(weakerisolationlevel)可以提高系统的并发度

隔离级别(Isolation Levels)

在不同隔离级别下,一个事务修改过的对象的值对其他并发事务的可见程度不同

  • 可以在事务开始前设置事务的隔离级别
SETTRANSACTIONISOLATIONLEVEL<isolation-level>;

读未提交(ReadUncommitted)

未提交事务(uncommittedtxn)所做的修改对其他事务可见
在这里插入图片描述
在这里插入图片描述

读提交(ReadCommitted)

只有已提交的事务(committedtxn)所做的修改才对其他事务可见。
在这里插入图片描述
在这里插入图片描述

可重复读(RepeatableRead)

如果一个事务不修改对象X的值,则该事务在任何时候读到的X值都等于事务启动时读到的X值。
在这里插入图片描述
在这里插入图片描述

可串行化(Serializable)

在这里插入图片描述

并发控制串行化

冲突可串行化

支持可串行化隔离级别的DBMS实施(enforce)的都是冲突可串行化

  • 冲突可串行化比一般可串行化的条件更严

  • 冲突可串行化更便于在DBMS中实施

冲突(Conflicts)

两个操作冲突(conflict),如果

  • 这两个操作属于不同的事务
  • 这两个操作涉及相同的对象,且至少一个操作是写

写-写冲突

写-写冲突可能导致脏写(dirtywrite)
在这里插入图片描述

写-读冲突

写-读冲突可能导致脏读(dirtyread)
在这里插入图片描述

读-写冲突

读-写冲突可能导致不可重复读(unrepeatable read)
在这里插入图片描述

冲突等价(ConflictEquivalence)

两个调度冲突等价(conflictequivalent),如果这两个调度涉及相同事务的相同操作

  • 每一对冲突的操作在两个调度中的顺序都相同
    在这里插入图片描述

冲突可串行化调度

如果一个调度冲突等价于某个串行调度,则该调度是冲突可串行化调度。
在这里插入图片描述
在这里插入图片描述

非冲突可串行化调度

在这里插入图片描述

总结

咱们玩归玩,闹归闹,别拿学习开玩笑。

本篇介绍了并发控制中的事务、调度、隔离级别和串行化。学习时要加深理解和记忆。

发布了130 篇原创文章 · 获赞 1797 · 访问量 31万+

猜你喜欢

转载自blog.csdn.net/JAck_chen0309/article/details/105649979
今日推荐