数据库概论 （八）并发处理

数据库并发控制

背景：数据库系统容许多用户操做，因此同一时间处理的事务可能多大上百个，所以必需要引入并发控制来保证数据的可靠性。

在并发环境下，事务的隔离性很难保证，所以会出现不少并发一致性问题。

丢失修改

丢失修改指一个事务的更新操做被另一个事务的更新操做替换。通常在现实生活中常会遇到，例如：T1 和 T2 两个事务都对一个数据进行修改，T1 先修改并提交生效，T2 随后修改，T2 的修改覆盖了 T1 的修改。

读脏数据

读脏数据指在不一样的事务下，当前事务能够读到另外事务未提交的数据。例如：T1 修改一个数据但未提交，T2 随后读取这个数据。若是 T1 撤销了此次修改，那么 T2 读取的数据是脏数据。

不可重复读

不可重复读指在一个事务内屡次读取同一数据集合。在这一事务还未结束前，另外一事务也访问了该同一数据集合并作了修改，因为第二个事务的修改，第一次事务的两次读取的数据可能不一致。例如：T2 读取一个数据，T1 对该数据作了修改。若是 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不一样。

幻影读

幻读本质上也属于不可重复读的状况，T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不一样。

---

产生并发不一致性问题的主要缘由是破坏了事务的隔离性，解决方法是经过并发控制来保证隔离性。并发控制能够经过封锁来实现，可是封锁操做须要用户本身控制，至关复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。

并发控制机制的任务

• 保证事务的隔离性 Isolation
• 对并发操做进行正确的，高效的调度
• 保证数据库的一致性

数据库一致性（Database Consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另外一个一致性状态。保证数据库一致性是指当事务完成时，必须使全部数据都具备一致的状态。在关系型数据库中，全部的规则必须应用到事务的修改上，以便维护全部数据的完整性。

并发控制的主要技术

• 封锁机制
• 时间戳 Timestamp
• 乐观控制法

数据库中的锁

读写锁

• 互斥锁（Exclusive），简写为 X 锁，又称写锁。
• 共享锁（Shared），简写为 S 锁，又称读锁。

有如下两个规定：

• 一个事务对数据对象 A 加了 X 锁，就能够对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。保证其余事务 在此期间没法读取和修改A。
• 一个事务对数据对象 A 加了 S 锁，能够对 A 进行读取操做，可是不能进行更新操做。加锁期间其它事务能对 A 加 S 锁，可是不能加 X 锁。由于X锁是互斥锁，与其余的任何锁都互斥，因此加不了。

锁的兼容关系以下：

意向锁

使用意向锁（Intention Locks）能够更容易地支持多粒度封锁。

在存在行级锁和表级锁的状况下，事务 T 想要对表 A 加 X 锁，就须要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁，那么就须要对表 A 的每一行都检测一次，这是很是耗时的。

IS锁

若是要对一个数据对象加上IS锁，那就表明准备向它的后裔节点加上S锁，例如若是要对R1中某个元组加S锁，则要首先对关系R1和数据库加IS锁 。

IX锁

若是要对一个数据对象加IX锁，就表明准备要对它的后裔节点加上X锁。例如要对R1中某个元组加X锁，则要首先对关系R1和数据库加IX锁。

SIX锁

SIX锁为S锁加上一个IX锁，也就是想要读整个表，并向对其中的一些数据进行修改，这个锁稍强于除X互斥锁之外的其余锁。

---

意向锁在原来的 X/S 锁之上引入了 IX/IS，IX/IS 都是表锁，用来表示一个事务想要在表中的某个数据行上加 X 锁或 S 锁。有如下两个规定：

• 一个事务在得到某个数据行对象的 S 锁以前，必须先得到表的 IS 锁或者更强的锁；
• 一个事务在得到某个数据行对象的 X 锁以前，必须先得到表的 IX 锁。

经过引入意向锁，事务 T 想要对表 A 加 X 锁，只须要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁，若是加了就表示有其它事务正在使用这个表或者表中某一行的锁，所以事务 T 加 X 锁失败。

各类锁的兼容关系以下：

解释以下：

• 任意 IS/IX 锁之间都是兼容的，由于它们只表示想要对表加锁，而不是真正加锁；
• 这里兼容关系针对的是表级锁，而表级的 IX 锁和行级的 X 锁兼容，两个事务能够对两个数据行加 X 锁。（事务 T1 想要对数据行 R1 加 X 锁，事务 T2 想要对同一个表的数据行 R2 加 X 锁，两个事务都须要对该表加 IX 锁，可是 IX 锁是兼容的，而且 IX 锁与行级的 X 锁也是兼容的，所以两个事务都能加锁成功，对同一个表中的两个数据行作修改。）

各类锁的偏序图

封锁协议

三级封锁协议

一级封锁协议

事务 T 要修改数据 A 时必须加 X 锁，直到 T 结束才释放锁。

能够解决丢失修改问题，由于不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。

二级封锁协议

在一级的基础上，要求读取数据 A 时必须加 S 锁，读取完立刻释放 S 锁。

能够解决读脏数据问题，由于若是一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。

三级封锁协议

在二级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。

能够解决不可重复读的问题，由于读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。

三个封锁协议的区别

• 一级只要求加X锁，对读取并不作要求，因此只解决了提交丢失的问题
• 二级要求在读取的时候添加S锁，并在读取以后当即释放
• 三级则要求S锁的释放时机在整个事务提交以后
• 全部高级封锁协议都基于低一级的封锁协议

两段锁协议

加锁和解锁分为两个阶段进行。

使用两段封锁协议的缘由：若是不使用封锁，或者光对并发执行的事务加锁，对锁的申请和释放时间却不加控制，就不能保证事务执行的可串行性，数据库的一致状态仍有可能被破坏。

• 在对任何数据进行读、写操做以前，事务首先要得到对该数据的封锁；
• 在释放一个封锁以后，事务再也不申请和得到任何其余封锁。

扩展阶段就是加锁的过程，收缩阶段就是释放锁的过程。

---

可串行化调度

是指经过并发控制，使得并发执行的事务结果与某个串行执行的事务结果相同。串行执行的事务互不干扰，不会出现并发一致性问题。

举例

可串行性

是并发事务正确调度的准则， 一个给定的并发调度，当且仅当它是可串行化的，才能被认定为是正确调度。

事务遵循两段锁协议是保证可串行化调度的充分条件。例如如下操做知足两段锁协议，它是可串行化调度。

lock-x(A)...lock-s(B)...lock-s(C)...unlock(A)...unlock(C)...unlock(B)
但不是必要条件，例如如下操做不知足两段锁协议，但它仍是可串行化调度。

lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(C)...unlock(C)

若并发的事务都遵照2PL， 则这些事务的任何并发调度都是可串行化的。

一次封锁协议能够避免死锁的发生，可是遵循两端锁协议有可能发生死锁，由于上锁并非一块儿完成的，在未上锁的时候，其中一个须要的数据被其余的事务拿到了锁，致使本来的事务没办法拿到锁，致使死锁的发生。

冲突操做

指的是不一样的事务对同一个数据的读写操做和写写操做。

一个读一个写，那么状态就不一致了，两个写操做也会致使数据库状态丢失、不一致

冲突可串行化

可串行化操做的充分条件：

• 一个调度Sc在保证冲突操做的次序不变的状况下，经过交换两个事务不冲突操做的次序获得另外一个调度Sc'，若是Sc'是串行的，称调度Sc为冲突可串行化的调度
• 一个调度是冲突可串行化，必定是可串行化的调度

严格两段锁协议

除了要求知足两段锁协议规定以外，还要求事务的排他锁必需要在事务提交以后释放。

能够解决脏数据的读取问题。

强两段锁协议

要求在知足两段锁协议以外，全部的锁都要在事务提交以后释放。

事务能够按照其提交的顺序完成串行化。

封锁粒度

MySQL 中提供了两种封锁粒度：行级锁以及表级锁。

应该尽可能只锁定须要修改的那部分数据，而不是全部的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。

可是加锁须要消耗资源，锁的各类操做（包括获取锁、释放锁、以及检查锁状态）都会增长系统开销。所以封锁粒度越小，系统开销就越大。

在选择封锁粒度时，须要在锁开销和并发程度之间作一个权衡。

粒度树

• 容许多粒度树中的每一个节点被独立的加锁
• 一个节点被加了锁意味着这个节点之下全部的子节点都要被加上相同类型的锁
• 因此有两种加锁的方式
  • 显示加锁，也就是直接指定加锁的粒度范围
  • 隐示加锁，从父节点那里继承、传递下来的相同类型的锁

因此系统在检查一个数据对象是否有锁的时候不只要检查有没有显示的加上锁，还要检查其上级节点有没有被加上锁。同时也不能忘了检查其子节点有没有锁与即将要加上的锁冲突，若是出现冲突也不能上锁。

部分图片与文字资料来自CS-Note