标准SQL规范中定义的四个事务隔离级别
1、更新丢失（lost update）：当系统允许两个事务同时更新同一数据是，发生更新丢失。
2、脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。3、非重复读（nonrepeatableread）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds thatanother committed transaction has modified or deleted the data. )
4、幻像（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows thatsatisfies a search condition and finds that another committed transaction has insertedadditional rows that satisfy the condition. )
下面是隔离级别及其对应的可能出现或不可能出现的现象
|
|
Dirty Read |
NonRepeatable Read |
Phantom Read |
| Read uncommitted |
Possible |
Possible |
Possible |
| Read committed |
Not possible |
Possible |
Possible |
| Repeatable read |
Not possible |
Not possible |
Possible |
| Serializable |
Not possible |
Not possible |
Not possible |
ORACLE的隔离级别
ORACLE提供了SQL92标准中的readcommitted和serializable，同时提供了非SQL92标准的read-only。
read committed：
这是ORACLE缺省的事务隔离级别。
事务中的每一条语句都遵从语句级的读一致性。
保证不会脏读；但可能出现非重复读和幻像。
serializable：
简单地说，serializable就是使事务看起来象是一个接着一个地顺序地执行。
仅仅能看见在本事务开始前由其它事务提交的更改和在本事务中所做的更改。
保证不会出现非重复读和幻像。
Serializable隔离级别提供了read-only事务所提供的读一致性（事务级的读一致性），同时又允许DML操作。
如果有在serializable事务开始时未提交的事务在serializable事务结束之前修改了serializable事务将要修改的行并进行了提交，则serializable事务不会读到这些变更，因此发生无法序列化访问的错误。（换一种解释方法：只要在serializable事务开始到结束之间有其他事务对serializable事务要修改的东西进行了修改并提交了修改，则发生无法序列化访问的错误。）
read-only：
遵从事务级的读一致性，仅仅能看见在本事务开始前由其它事务提交的更改。
不允许在本事务中进行DML操作。
read only是serializable的子集。它们都避免了非重复读和幻像。区别是在read only中是只读；而在serializable中可以进行DML操作。
Export with CONSISTENT =Y sets the transaction to read-only.
read committed和serializable的区别和联系：
事务1先于事务2开始，并保持未提交状态。事务2想要修改正被事务1修改的行。事务2等待。如果事务1回滚，则事务2（不论是read committed还是serializable方式）进行它想要做的修改。如果事务1提交，则当事务2是read committed方式时，进行它想要做的修改；当事务2是serializable方式时，失败并报错“Cannot serialize access”，因为事务2看不见事务1提交的修改，且事务2想在事务一修改的基础上再做修改。
在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:
◆未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
◆授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
◆可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
◆序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
通过前面的介绍已经知道，通过选用不同的隔离等级就可以在不同程度上避免前面所提及的在事务处理中所面临的各种问题。所以，数据库隔离级别的选取就显得尤为重要，在选取数据库的隔离级别时，应该注意以下几个处理的原则：
首先，必须排除“未授权读取”，因为在多个事务之间使用它将会是非常危险的。事务的回滚操作或失败将会影响到其他并发事务。第一个事务的回滚将会完全将其他事务的操作清除，甚至使数据库处在一个不一致的状态。很可能一个已回滚为结束的事务对数据的修改最后却修改提交了，因为“未授权读取”允许其他事务读取数据，最后整个错误状态在其他事务之间传播开来。
其次，绝大部分应用都无须使用“序列化”隔离（一般来说，读取幻影数据并不是一个问题），此隔离级别也难以测量。目前使用序列化隔离的应用中，一般都使用悲观锁，这样强行使所有事务都序列化执行。
剩下的也就是在“授权读取”和“可重复读取”之间选择了。我们先考虑可重复读取。如果所有的数据访问都是在统一的原子数据库事务中，此隔离级别将消除一个事务在另外一个并发事务过程中覆盖数据的可能性（第二个事务更新丢失问题）。这是一个非常重要的问题，但是使用可重复读取并不是解决问题的唯一途径。