13.2. 事务隔离

13.2.1. 读已提交隔离级别

读已提交是 PostgreSQL 里的缺省隔离级别。 当一个事务运行在这个隔离级别时， SELECT查询(没有FOR UPDATE/SHARE的子句)只能看到查询开始之前已提交的数据 而无法看到未提交的数据或在查询执行期间其它事务已提交的数据。 不过SELECT看得见其自身所在事务中前面尚未提交的更新结果。 实际上，SELECT 查询看到一个在查询开始运行的瞬间该数据库的一个快照。 请注意，在同一个事务里两个相邻的SELECT命令可能看到不同的快照， 因为其它事务会在第一个SELECT执行期间提交。

UPDATE，DELETE，SELECT FOR UPDATE和SELECT FOR SHARE命令在搜索目标行时的行为和 SELECT 一样： 它们只能找到在命令开始的时候已经提交的行。 不过，找到这样的目标行的时候可能已经被其它并发事务更新、删除、锁住。在这种情况下， 即将进行的更新将等待第一个事务提交或者回滚(如果它还在处理)。 如果第一个事务回滚，那么它的作用将忽略，而第二个事务将继续更新最初发现的行。 如果第一个事务提交，那么如果第一个事务删除了该行，则第二个事务将忽略该行， 否则它将试图在该行的已更新的版本上施加它的操作。系统将重新计算命令搜索条件(WHERE子句)， 看看该行已更新的版本是否仍然符合搜索条件。如果符合，则第二个事务从该行的已更新版本开始继续其操作。 如果是SELECT FOR UPDATE和SELECT FOR SHARE 则意味着把已更新的行版本锁住并返回给客户端。

: 因为上面的规则，正在更新的命令可能会看到不一致的快照： 它们可以看到影响它们更新的并发命令的效果，但是却看不到那些命令对数据库里其它行的作用。 这样的行为令读已提交模式不适合用于哪种涉及复杂搜索条件的命令。 不过，它对于简单的情况而言是正确的。 比如，假设我们用类似下面这样的命令更新银行余额：

BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;

如果两个并发事务试图同时修改帐号12345的余额，那我们很明显希望第二个事务是从已更新过的行版本上进行更新。 因为每个命令只是影响一个已经决定了的行，因此让它看到更新后的版本不会导致任何不一致的问题。

在读取已提交模式中，更复杂的使用可能产生不需要的结果。比如： 考虑删除命令操作正在数据中添加和删除其都限制条件由另一个命令。 website是个有两行数据表。website.hits分别为9和 10：

BEGIN;
UPDATE website SET hits = hits + 1;
-- run from another session:  DELETE FROM website WHERE hits = 10;
COMMIT;

DELETE不会影响在UPDATE前后website.hits = 10的行。 这是因为发生更新前值9的行跳过，当UPDATE完成，DELETE获取一个锁。 新行值不再是10而是11，没有匹配的条件。

因为在读已提交模式里，每个命令都是从一个新的快照开始的，而这个快照包含所有到该时刻为止已提交的事务， 因此同一事务中后面的命令将看到任何已提交的其它事务的效果。 这里关心的问题是在单个命令里是否看到数据库里绝对一致的视图。

读已提交模式提供的部分事务隔离对于许多应用而言是足够的，并且这个模式速度快，使用简单。 不过，对于做复杂查询和更新的应用，可能需要保证数据库有比读已提交模式更加严格的一致性视图。

13.2.2. 可串行化隔离级别

可串行化级别提供最严格的事务隔离。 这个级别模拟串行的事务执行，就好像事务将被一个接着一个那样串行(而不是并行)的执行。 不过，使用这个级别的应用必须准备在串行化失败的时候重新启动事务。

当一个事务处于可串行化级别时， SELECT查询只能看到在事务开始之前已提交的数据而看不到未提交的数据或事务执行期间其它并发事务已提交的修改。 不过，SELECT 看得见其自身所在事务中前面尚未提交的更新结果。 可串行化的SELECT看到的是该事务开始时的快照，而不是该事务内部当前查询开始时的快照，这个行为和读已提交级别是不一样的。 这样，同一个事务内部后面的SELECT命令总是看到同样的数据。 它们看不到其它事务所提交在它们自己的事务开始后所做的更改。 （这种行为可以报表应用程序的理想选择。）

UPDATE,DELETE,SELECT FOR UPDATE, 和SELECT FOR SHARE在搜索目标行时的行为和 SELECT 一样： 它们将只寻找在事务开始的时候已经提交的目标行。 但是，这样的目标行在被发现的时候可能已经被另外一个并发的事务更新、删除、锁住。在这种情况下， 可串行化的事务将等待第一个正在更新的事务提交或者回滚(如果它仍然在处理中)。 如果第一个事务回滚，那么它的影响将被忽略，而这个可串行化的就可以继续更新它最初发现的行。 但是如果第一个事务被提交了(并且实际上更新或者删除了该行，而不只是锁住它)那么可串行化事务将回滚，并返回下面信息：

ERROR:  could not serialize access due to concurrent update

因为一个可串行化的事务在开始之后不能更改或者锁住被其它事务更改过的行。

当应用收到这样的错误信息时，它应该退出当前的事务然后从新开始进行整个事务。 第二次运行时，该事务看到的快照将包含前一次已提交的修改，所以不会有逻辑冲突。

请注意只有更新事务才需要重试，只读事务从来没有串行化冲突。

可串行化事务级别提供了严格的保证：每个事务都看到一个完全一致的数据库视图。 不过，如果并发更新令数据库不能维持串行执行的样子，那么应用必须准备重试事务。 因为重做复杂事务的开销可能是非常可观的， 所以我们只建议当更新命令中包含复杂逻辑并且在读已提交级别中可能导致错误结果的时候才使用可串行化级别。 可串行化模式只是在这样的情况下是必要的： 一个事务连续做若干个命令，而这几个命令必须看到完全相同的数据库视图。

 class | value 
-------+-------
     1 |    10
     1 |    20
     2 |   100
     2 |   200

SELECT SUM(value) FROM mytab WHERE class = 1;

SELECT SUM(value) FROM mytab WHERE class = 2;