选择隔离级别的时候，既需要考虑数据的一致性，避免脏数据，又要考虑系统性能的问题。下面我们通过商品抢购的场景来讲述这4种隔离级别的区别

未提交读（read uncommitted）

未提交读是最低的隔离级别，其含义是允许一个事务读取另一个事务没有提交的数据。未提交读是一种危险的隔离级别，所以在实际的开发中应用不广，但是它的优点在于并发能力高，适合那些对数据一致性没有要求而追求高并发的场景，它的最大坏处是可能发生脏读。表6-3展示了可能发生的脏读现象。

脏读现象

在表6-3所示的T3时刻，因为采用未提交读，所以事务2可以读取事务1未提交的库存1，事务2扣减库存后则库存为0，然后事务2提交事务，库存就变为了0，而事务1在T5时刻回滚事务，因为第一类丢失更新已经被克服，所以它不会将库存回滚到2，那么最后的库存就变为了0，这样就出现了错误。为了克服脏读的问题，数据库标准提供了读写提交的级别。

2. 读写提交（read committed）

读写提交隔离级别，是指一个事务只能读取另一个事务已经提交的数据，不能读取未提交的数据。例如，表6-3的场景在限制为读写提交隔离级别后，就变为表6-4描述的场景了。

               表6-4 克服脏读

在T3时刻，由于采用了读写提交的隔离级别，因此事务2读取不到事务1中未提交的库存2，T4时刻扣减库存的结果依旧为2，然后事务2提交事务，在T5时刻库存就变为了2。在T6时刻，事务1回滚，因为第一类丢失更新已经克服，所以最后库存为2，这是一个正确的结果。但是读写提交也会产生表6-5所描述的不可重复读现象。

                 表6-5 不可重复读现象

在T3时刻，事务2读取库存，因为事务1未提交事务，所以读出的库存为1，于是事务2认为当前可扣减库存。在T4时刻，因为事务1已经提交事务，所以在T5时刻，事务2扣减库存的时候就发现库存为0，于是就无法扣减库存了。这里的问题在于事务2之前认为可以扣减，而到扣减那一步却发现已经不可以扣减，于是库存对事务2而言是一个可变化的值，这样的现象称为不可重复读，这就是读写提交的一个不足之处。为了克服这个不足，数据库的标准还提供了可重复读的隔离级别，它能够克服不可重复读的问题

3. 可重复读（repeatable read）

可重复读的目标是克服读写提交中出现的不可重复读的现象，因为在读写提交的时候，可能出现一些值的变化，影响当前事务的运行，如上述的库存是一个变化的值。这个时候数据库标准提出了可重复读的隔离级别，能够克服不可重复读的问题，如表6-6所示。

                    表6-6 克服不可重复读

可以看到，事务2在T3时刻尝试读取库存，但是此时这个库存已经被事务1读取，所以这个时候数据库就阻塞事务2的读取，直至事务1提交，事务2才能读取库存的值。此时已经是T5时刻，而读取到的值为0，这时就已经无法扣减了，显然在读写提交中出现的不可重复读的现象被消除了。但是，这样做也会引发新的问题——幻读。假设现在商品交易正在进行中，而后台有人也在进行查询和打印的业务，让我们看看可能出现的场景，如表6-7所示。

						表6-7 幻读现象

这便是幻读现象。可重复读和幻读是读者比较难以理解的内容，这里简单解释一下。这里的交易记录数不是数据库存储的值，而是一个统计值，商品库存则是数据库存储的值，这一点是要注意的。也就是说，幻读是针对多条记录而言的，例如，T6时刻打印的51笔交易记录就是多条数据库记录。可重复读是针对数据库的一条记录而言的，例如，商品的库存是以数据库里面的一条记录存储的，它可以产生可重复读，而不能产生幻读。

串行化（serializable）

串行化是数据库最高的隔离级别，它会要求所有SQL语句都按照顺序运行，这样就可以克服上述隔离级别出现的各种问题，能够完全保证数据的一致性。

使用合理的隔离级别

						表6-8 隔离级别和可能发生的现象

作为互联网应用开发者，在开发高并发业务时需要时刻记住隔离级别的各种概念和可能发生的相关现象，这是数据库事务的核心内容，也是互联网企业关注的重要内容。在企业的生产实践中，选择隔离级别一般会以读写提交为主，它能够防止脏读，但不能避免不可重复读和幻读。为了克服数据不一致和性能问题，程序开发者还设计了乐观锁，甚至使用其他数据库，例如使用Redis作为数据载体。对于隔离级别，不同的数据库的支持也是不一样的。例如，racle只能支持读写提交和串行化，而MySQL则能够支持4种，racle默认的隔离级别为读写提交，MySQL默认的隔离级别则是可重复读。