数据库点滴

 

实现分布式事务的关键就是两阶段提交协议。在此协议中，一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下：

•	应用程序调用事务协调器中的提交方法。
•	事务协调器将联络事务中涉及的每个资源管理器，并通知它们准备提交事务（这是第一阶段的开始）。
•	为 了以肯定的方式响应准备阶段，资源管理器必须将自己置于以下状态：确保能在被要求提交事务时提交事务，或在被要求回滚事务时回滚事务。大多数资源管理器会 将包含其计划更改的日记文件（或等效文件）写入持久存储区中。如果资源管理器无法准备事务，它会以一个否定响应来回应事务协调器。
•	事务协调器收集来自资源管理器的所有响应。
•	在 第二阶段，事务协调器将事务的结果通知给每个资源管理器。如果任一资源管理器做出否定响应，则事务协调器会将一个回滚命令发送给事务中涉及的所有资源管理 器。如果资源管理器都做出肯定响应，则事务协调器会指示所有的资源管理器提交事务。一旦通知资源管理器提交，此后的事务就不能失败了。通过以肯定的方式响 应第一阶段，每个资源管理器均已确保，如果以后通知它提交事务，则事务不会失败。

图 1 和图 2 通过两个顺序图来说明两阶段提交协议。

图 1 事务提交

图 1 显示事务成功（提交）。图 2 显示由于某种原因，其中一个资源管理器无法提交时的两阶段提交协议。

图 2 事务被回滚

 

数据库索引的类型及其适用

PostgreSQL 提供了好几种索引类型∶ B-tree，R-tree，GiST 和散列．每种索引类型都比较适合某些特定的查询类型， 因为它们用了不同的算法． 缺省时， CREATE INDEX 命令将创建一个 B-tree 索引，这也使最常见的情形．特别是在 一个索引了的列涉及到使用下列操作符之一进行比较的时候， PostgreSQL 的查询优化器都会考虑使用 B-tree 索引∶ <, <=, =, >=, >

　　R-tree 索引特别适合于空间数据．要创建一个 R-tree 索引， 使用下面形式的命令

　　CREATE INDEX name ON table USING RTREE (column);

　　当一个索引了的列涉及到使用下列操作符之一进行比较的时候， PostgreSQL 的查询优化器都会考虑使用 R-tree 索引∶ <<, &<, &>, >>, @, ~=, && (请参考 Section 6.9 获取这些操作符的含义．)

　　当一个索引了的列涉及到使用 = 操作符 进行比较的时候，查询优化器会考虑使用散列索引． 下面的命令用于创建散列索引∶

　　CREATE INDEX name ON table USING HASH (column);

　　注意: 测试表明 PostgreSQL 的散列索引和 B-tree 索引类似或者慢一些， 而且散列索引的尺寸和制作时间要差很多。而且在高度并发的条件下，散列 索引的性能也很差。因此，我们不建议使用散列索引。

　　B-tree 索引是一个 Lehman-Yao 高并发 B-tree 的实 现。R-tree 索引用 Guttman 的二次分割算法实现了标准的 R-tree。 hash（散列）索引是 Litwin 的线性散列的一个实 现。我们单独的列出这些所用的算法是要表明 所有这些访问模式都是完全动态的并且不必进行周期性的优化（例如，象静 态散列算法常见的那样）。

 

数据库事务的四个基本性质（ACID）
1. 原子性（Atomicity）
事务的原子性是指事务中包含的所有操作要么全做，要么全不做（all or none）。

2. 一致性（Consistency）
在事务开始以前，数据库处于一致性的状态，事务结束后，数据库也必须处于一致性状态。

拿银行转账来说，一致性要求事务的执行不应改变A、B 两个账户的金额总和。如果没有这种一致性要求，转账过程中就会发生钱无中生有，或者不翼而飞的现象。事务应该把数据库从一个一致性状态转换到另外一个一致性状态。

3. 隔离性（Isolation）
事务隔离性要求系统必须保证事务不受其他并发执行的事务的影响，也即要达到这样一种效果：对于任何一对事务T1 和 T2，在事务 T1 看来，T2 要么在 T1 开始之前已经结束，要么在 T1 完成之后才开始执行。这样，每个事务都感觉不到系统中有其他事务在并发地执行。

4. 持久性（Durability）
一个事务一旦成功完成，它对数据库的改变必须是永久的，即便是在系统遇到故障的情况下也不会丢失。数据的重要性决定了事务持久性的重要性。

 

在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:

◆未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

◆授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

◆可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

◆序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

通过前面的介绍已经知道，通过选用不同的隔离等级就可以在不同程度上避免。

 

数据库并发控制协议

封锁的目的是为了保证能够正确地调度并发操作。为此，在运用X锁和S锁这两种基本封锁，对一定粒度的数据对象加锁时，还需要约定一些规则，例如，应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议（locking protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议，它们分别在不同的程度上为并发操作的正确调度提供一定的保证。本节介绍保证数据一致性的三级封锁协议和保证并行调度可串行性的两段锁协议，下一节将介绍避免死锁的封锁协议。

（5）保证数据一致性的封锁协议――三级封锁协议

对并发操作的不正确调度可能会带来四种数据不一致性：丢失或覆盖更新、脏读、不可重复读和幻想读。三级封锁协议分别在不同程度上解决了这一问题。

①1级封锁协议

1级封锁协议的内容是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（commit）和非正常结束（rollback）。

1级封锁协议可以防止丢失或覆盖更新，并保证事务T是可以恢复的。例如，下图使用1级封锁协议解决了定飞机票例子的丢失更新问题。

上图中，事务1在读A进行修改之前先对A加X锁，当事务2再请求对A加X锁时被拒绝，只能等事务1释放A上的锁。事务1修改值A=15写回磁盘，释放A上的X锁后，事务2获得对A的X锁，这时他读到的A已经是事务1更新过的值15，再按此新的A值进行运算，并将结果值A=14回到磁盘。这样就避免了丢失事务1的更新。

在1级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和脏读。

②2级封锁协议

2级封锁协议的内容是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。

2级封锁协议除防止了丢失或覆盖更新，还可进一步防止脏读。例如，下图使用2级封锁协议解决了脏读的问题。

下图中，事务1在对C进行修改之前，先对C加X锁，修改其值后写回磁盘。这时事务2请求C加上S锁，因T1已在C上加了X锁，事务2只能等待事务1释放它。之后事务1因某种原因被撤销，C恢复为原值100，并释放C上的X锁。事务2获得C上的S锁，读C=100。这就避免了事务2脏读数据。

在2级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。

③3级封锁协议

3级封锁协议的内容是：1级封锁协议加上事务T在读取数据之前必须先对其加S锁，直到事务结束才释放。

3级封锁协议除防止丢失或覆盖更新和不脏读数据外，还进一步防止了不可重复读和幻想读。例如下图，使用3级封锁协议解决了不可重复读和幻像读问题。

上图中，事务1在读A，B之前，先对A，B加S锁，这样其他事务只能再对A，B加S锁，而不能加X锁，即其他事务只能读A，B，而不能修改它们。所以当事务2为修改B而申请对B的X锁时被拒绝，使其他无法执行修改操作，只能等待事务1释放B上的锁。接着事务1为验算再读A，B，这时读出的B仍是100，求和结果仍为150，即可重复读。

上述三级协议的主要区别在于什么操作需要申请封锁以及何时释放锁（即持锁时间）。三级封锁协议可以总结为下表。

	X锁		S锁		一致性保证
	操作结束释放	事务结束释放	操作结束释放	事务结束释放	不丢失修改	不脏读	可重复读
1级封锁协议		√			√
2级封锁协议		√	√		√	√
3级封锁协议		√		√	√	√	√

（6）保证并行调度可串行性的封锁协议――两段封锁协议

可串行性是并行调度正确性的唯一准则，两段锁（two-phase locking，简称2PL）协议是为保证并行调度可串行性而提供的封锁协议。
两段封锁协议规定：

①在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁，而且②在释放一个封锁之后，事务不再获得任何其他封锁。
所谓“两段”锁的含义是，事务分为两个阶段，第一阶段是获得封锁，也称为扩展阶段，第二阶段是释放封锁，也称为收缩阶段。
例如，事务1的封锁序列是：

Slock A... Slock B… Xlock C… Unlock B… Unlock A… Unlock C;

事务2的封锁序列是：

Slock A... Unlock A… Slock B… Xlock C… Unlock C… Unlock B;

则事务1遵守两段封锁协议，而事务2不遵守两段封锁协议。

可以证明，若并行执行的所有事务均遵守两段锁协议，则对这些事务的所有并行调度策略都是可串行化的。因此我们得出如下结论：所有遵守两段锁协议的事务，其并行的结果一定是正确的。

需要说明的是，事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。即可串行化的调度中，不一定所有事务都必须符合两段封锁协议。例如，在下图中，（a）和（b）都是可串行化的调度，但（a）遵守两段锁协议，（b）不遵守两段锁协议。

（a）遵守两段封锁协议	（b）不遵守两段锁协议
Slock B 读B=2 Y   B Xlock A               Slock A               等待 A   Y+1 写回A=3 Unlock B Unlock A               Slock A               读A=3               Y   A               Xlock B               B   Y+1               写回B=4               Unlock B               Unlock A	Slock B 读B=2 Y   B Unlock B Xlock A               Slock A               等待 A   Y+1 写回A=3 Unlock A               Slock A               读A=3               Y   A Unlock A               Xlock B               B   Y+1               写回B=4               Unlock B