事务隔离(Isolation)，指的是在数据库系统中并发事务(Transaction)之间的可见性，以及如何相互影响的定义。事务隔离是ACID的四个特性（原子性、一致性、隔离性、持久性）之一。在ANSI/ISO的SQL标准中，定义了四个事务隔离级别，分别用于不同的场合。在传统的数据库系统的实现中，一般实现不同等级的隔离性的方法是使用锁定(lock)，根据具体需求可细分为读取锁(read lock)、写入锁(write lock)和范围锁(range-locks)。
可序列化
可序列化(SERIALIZABLE)是最高的隔离级别。在此级别下，所有事务的完整性都被保留，这意味着所有的事务可以被序列化地执行。当只有两个事务之前没有任何冲突时，才能并发地执行。
可重复读取
在可重复读取(REPEATABLE READS)级别下，数据库系统会在在整个事务期间保持所有读取锁和写入锁，但相较于可序列化，范围锁不会被管理，所以幻象读取(phantom reads)可能会出现。
授权读取
在授权读取(READ COMMITTED)级别下，数据库系统在整个事务期间保持写入锁，但读取锁会在SELECT执行后立即释放，所以不可重复读取(non-repeatable reads)可能会出现。
未授权读取
未授权读取(READ UNCOMMITTED)是最低的隔离级别。这个级别允许出现肮脏读取(dirty reads)。
下列的示例解释了幻象读取(phantom reads)、不可重复读取(non-repeatable reads)和肮脏读取(dirty reads)。数据在下表中定义：
| id | name | age |
|---|---|---|
| 1 | Joe | 20 |
| 2 | Jill | 25 |
肮脏读取
当一个事务试图读取另一个还未提交的事务正在修改的某一行数据时，肮脏读取(dirty reads)就会发生。
下列示例中，事务2正在修改某行，但还没有提交。事务1试图读取这一行。如果事务2回滚了(rolls back)变更，或者后面又进行了其他的修改，那么事务1就获得了肮脏(dirty)的数据。
| 事务1 | 事务2 |
|---|---|
sql/* Query 1 */SELECT * FROM users WHERE id = 1; |
|
sql/* Query 2 */UPDATE users SET age = 21 WHERE id = 1;/* No commit here */ |
|
sql/* Query 1 */SELECT * FROM users WHERE id = 1; |
|
sqlROLLBACK; /* lock-based DIRTY READ */ |
不可重复读取
当一个事务正在执行的时候，对某一行两次读取的结果不一致，则称发生了不可重复读取(non-repeatable reads)。
以下示例中事务1读取了某行，之后事务2立刻修改了这一行并提交了结果，事务1再读取这一行的时候，结果就不一致了。
| 事务1 | 事务2 |
|---|---|
sql/* Query 1 */SELECT * FROM users WHERE id = 1; |
|
sql/* Query 2 */UPDATE users SET age = 21 WHERE id = 1;COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */ |
|
sql/* Query 1 */SELECT * FROM users WHERE id = 1;COMMIT; /* lock-based REPEATABLE READ */ |
幻象读取
幻象读取(phantom reads)指的是两次集合查询之间返回了不一致的结果。以下示例展现了这一现象。
| 事务1 | 事务2 |
|---|---|
sql/* Query 1 */SELECT * FROM usersWHERE age BETWEEN 10 AND 30; |
|
sql/* Query 2 */INSERT INTO users VALUES ( 3, 'Bob', 27 );COMMIT; |
|
sql/* Query 1 */SELECT * FROM usersWHERE age BETWEEN 10 AND 30; |
隔离级别与读取现象
| 隔离级别 | 肮脏读取 | 不可重复读取 | 幻象读取 |
|---|---|---|---|
| 未授权读取 | 可能发生 | 可能发生 | 可能发生 |
| 授权读取 | - | 可能发生 | 可能发生 |
| 可重复读取 | - | - | 可能发生 |
| 可序列化 | - | - | - |
隔离级别与锁定
| 隔离级别 | 写入锁 | 读取锁 | 范围锁 |
|---|---|---|---|
| 未授权读取 | - | - | - |
| 授权读取 | 需要 | - | - |
| 可重复读取 | 需要 | 需要 | - |
| 可序列化 | 需要 | 需要 | 需要 |
乐观锁与多版本并发控制
在锁定控制的数据库系统中，死锁(dead lock)指的是两个以上的事务互相依赖等待，从而都被阻塞的现象。与多线程程序的设计不同，锁定控制的数据库中死锁出现是很正常现象，而且是无法根本上避免的。当死锁出现并且被数据库系统检测到时，所有死锁的事务都会被驳回，用户不得不根据需要进行重提交。然而死锁不仅检测代价是很高昂的，而且还会浪费大量资源，如果死锁频繁出现，会大大降低数据库系统的并发性能。但我们不能为了避免死锁而降低隔离等级，而且有一点可以肯定的是，事务隔离级别越高，死锁出现的概率就越大。
为了提高性能，乐观锁(optimistic locking)机制被提出。与传统的悲观锁(optimistic locking)「先取锁再访问」的保守策略不同，乐观锁相信事物之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
一种可靠的乐观锁的实现是使用「多版本控制(multi-version control)」，即在每一行加一个version属性。修改这一行时将version增加1，写回数据库要检查当前的version值是否还是获取时的那个值了。如果还是，说明期间没有其他事务对其修改，直接提交即可，如果已经不是了，说明期间已经有别的事务修改了这一行，当前事务获取的数据已经过期了，事务失败。
在PostgreSQL及MySQL的InnoDB引擎的实现中，多版本控制的乐观锁是内置的(build-in)，所以这个无需手动添加version字段。默认情况下，PostgreSQL/MySQL会尽可能使用乐观锁，除非遇到显式的锁定命令，如"select * from sometable for update"这样的语句，才会主动使用悲观锁。<o
参考资料
http://en.wikipedia.org/wiki/Isolation_(database_systems)http://www.blogjava.net/loocky/archive/2006/11/15/81138.html