d提交QRead CommittedQ?br /> 当一个事务运行在q个隔离U别Ӟ 一个SELECT 查询只能看到查询开始之前提交的数据而永q无法看到未提交的数据或者是在查询执行时其他q行的事务提交做的改变。（不过SELECT 的确看得见同一ơ事务中前面更新的结果．即它们q没提交也看得到Q）实际上，一个SELECT 查询看到一个在该查询开始运行的瞬间该数据库C个快照。请注意两个盔R的SELECT 可能看到不同的数据，哪怕它们是在同一个事务里Q因为其它事务会在第一个SELECT执行的时候提?
d提交隔离U别
d提交QRead CommittedQ??PostgreSQL 里的~省隔离U别?当一个事务运行在q个隔离U别Ӟ 一?SELECT 查询只能看到查询开始之前提交的数据而永q无法看到未提交的数据或者是在查询执行时其他q行的事务提交做的改变?Q不q?SELECT 的确看得见同一ơ事务中前面更新的结果。即使它们还没提交也看得到。） 实际上，一?SELECT 查询看到一个在该查询开始运行的瞬间该数据库的一个快照?h意两个相ȝ SELECT 命o可能看到不同的数据，哪怕它们是在同一个事务里Q?因ؓ其它事务会在W一个SELECT执行的时候提交．
UPDATEQ?DELETEQ?或?SELECT FOR UPDATE 在搜索目标行的时候的行ؓ和SELECT 一P 它们只能扑ֈ在命令开始的时候已l提交的行?不过Q这L目标行在被找到的时候可能已l被其它q发的事务更斎ͼ或者删除，或者标Cؓ更新的）?在这U情况下Q即进行的更新等待第一个更C务提交或者回滚（如果它还在处理）?如果W一个更新回滚，那么它的作用被忽略Q而第二个更新者将l箋更新最初发现的行?如果W一个更新者提交，那么如果W一个更新者删除了该行Q则W二个更新者将忽略该行Q?否则它将试图在该行的已更新的版本上施加它的操作。系l将重新计算命o搜烦条gQWHERE 子句Q， 看看该行已更新的办不那是否仍然符合搜索条件。如果是Q则W二个更新l其操作Q从该行的已更新版本开始?
因ؓ上面的规则，正在更新的命令可能会看到不一致的快照 --- 它们可以看到影响它们试图更新的ƈ发更新命令的效果Q?但是它们看不到那些命令对数据库里其它行的作用?q样的行Zod提交模式不适合用于哪种涉及复杂搜烦条g的命令?不过Q它对于单的情况而言是正的。比如，假设我们用类g面这L命o更新银行余额Q?
BEGIN; UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345; UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534; COMMIT;如果两个q发事务试图修改帐号 12345 的余额，那我们很明显希望W二个事务是从帐戯的已l更新过的版本上q行更新?因ؓ每个命o只是影响一个已l决定了的行Q因此让它看到更新后的版本不会导致Q何不一致的问题?
因ؓ在读已提交模式里Q每个新的命令都是从一个新的快照开始的Q而这个快照包含所有到该时Mؓ止已l提交的事务Q?因此同一个事务里的后面的命o看CQ何已提交的ƈ发事务的效果?q里要考虑的问题是我们在一个命令里是否看到数据库里l对一致的视图?
d提交模式提供的部分事务隔d于许多应用而言是够的Qƈ且这个模式速度快，使用单?不过Q对于做复杂查询和更新的应用Q可能需要保证数据库有比d提交模式提供的更加严格的一致性视图?
12.2.2. 可串行化隔离U别
可串行化QSerializableQ?U别提供最严格的事务隔R?q个U别模拟串行的事务执行， 好象事务将被一个接着一个那样串行的Q而不是ƈ行的执行?不过Q用这个别的应用必须准备在串行化p|的时候重新发动事务．
当一个事务处于可串行化别， 一?SELECT 查询只能看到在事务开始之前提交的数据而永q看不到未提交的数据或事务执行中其他q行事务提交的修攏V?Q不q，SELECT 的确看得到同一ơ事务中前面的更新的效果。即使事务还没有提交也一栗） q个行ؓ和读已提交别是不太一P它的 SELECT 看到的是该事务开始时的快照，而不是该事务内部当前查询开始时的快照?q样Q一个事务内部后面的 SELECT 命oL看到同样的数据?
UPDATEQ?DELETEQ和 SELECT FOR UPDATE 在搜索目标行上的行ؓ?SELECT 一P 它们只L在事务开始的时候已l提交的目标行。但是， q样的目标行在被发现的时候可能已l被另外一个ƈ发的事务更新了（或者是删除或者是标记为更斎ͼ?在这U情况下Q可串行化的事务等待第一个正在更新的事务提交或者回滚（如果它仍然在处理中）?如果W一个更新者回滚，那么它的影响被忽略Q?而这个可串行化的可以l更新它最初发现的行?但是如果W一个更新者提交了Qƈ且实际上更新或者删除了该行Q而不只是为更新选中它）那么可串行化事务回滚，q返回下面信?
ERROR: Can't serialize access due to concurrent update因ؓ一个可串行化的事务在可串行化事务开始之后不能更改被其他事务更改q的行?
当应用收到这L错误信息Ӟ它应该退出当前的事务然后从头开始重新进行整个事务?W二ơ运行时Q该事务看到的前一ơ提交的修改是该数据库初始的样子中的一部分Q?所以把新版本的行作为新事务更新的v点不会有逻辑冲突?
h意只有更C务才需要重试，只读事务从来没有串行化冲H．
可串行化事务U别提供了严格的保证Q每个事务都看到一个完全一致的数据库的视图?不过Q如果ƈ行更Co数据库不能维持串行执行的样子Q那么应用必d备重试事务?因ؓ重做复杂的事务的开销可能是非常可观的Q所以我们只在更新命令中包含_复杂的逻辑Q?在读已提交别中可能D错误的结果的情况下才使用?最常见的是Q可串行化模式只是在q样的情况下是必要的Q一个事务连l做若干个命令， 而这几个命o必须看到数据库完全一L视图?/p>
本文来自CSDN博客Q{载请标明出处Qhttp://blog.csdn.net/lanbaibai/archive/2004/06/29/29547.aspx
]]>