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

数据库并发控制

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

在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题。

丢失修改

丢失修改指一个事务的更新操作被另外一个事务的更新操作替换。一般在现实生活中常会遇到，例如：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