聊聊数据库的事务隔离级别

前几天一个金融行业的朋友和我讨论数据库选型的事情，他们在选择分布式数据库的时候发现这些数据库支持的事务隔离级别与Oracle有较大差异，有位领导认为对事务隔离级别的支持能力说明了数据库在并发处理方面的能力，因此要在选型中占有比较高的分值，甚至要在较高事务隔离级别下测试数据库的并发性能。他对此持不同的看法。

数据库事务隔离级别的概念最早是在1981年由IBM的Jim Gray等人提出的，他们在论文《The Notions of Consistency and Predicate Locks in a Database System》中定义了四种隔离级别，分别是：

• 读未提交（Read uncommitted）：最低的隔离级别，允许一个事务读取另一个未提交事务的数据，可能导致脏读、不可重复读、幻读等问题。
• 读提交（Read committed）：目前被应用最为广泛的使用的事务隔离级别，只允许一个事务读取另一个已提交事务的数据，可以避免脏读，但不能避免不可重复读、幻读等问题。
• 可重复读（Repeatable read）：较高的隔离级别，保证一个事务在执行过程中对同一数据的多次读取结果都是一致的，可以避免脏读、不可重复读，但不一定能避免幻读等问题。
• 串行化（Serializable）：最高的隔离级别，要求事务串行执行，不允许并发访问和修改同一数据，可以避免脏读、不可重复读、幻读等所有问题，但性能最差。

数据库的多种事务隔离级别是想为应用开发者提供不同的并发控制，从而适应各种不同的应用应用场景。这在T/S架构流行的80/90年代应用广泛。那时候所有的计算都只能在主机或者小型机上完成，因此数据库提供的这个功能可以大大简化应用开发。C/S架构出现后，特别是后来的三层架构大行其道的时代之后，Read Committed变成了最为常用的事务隔离级别，其他事务隔离级别大多数都基本上不用了。比Read Committed更高的事务隔离级别被前置到应用前端或者中间层来实现了。

更高的事务隔离级别的最著名的例子就是分页查询，在RC隔离级别下，哪怕是在一个事务中，我们在前端分页查询同一个数据时，都会看到“脏数据”，因为这些数据在我们读的时候也会有人同时在修改和写入新的满足条件的数据。对于这种方式的处理方法一般来说就是容忍“脏数据”，互联网应用一般都是这样处理的。而对于数据一致性要求很高的财务系统，则一般采用在中间层缓存数据或者使用全局临时表缓存数据的方式来确保数据的一致性。

现在的应用较少的通过事务隔离级别来处理这种高一致性要求的数据的主要原因还是因为技术发展了，多层架构让中间层有了更为强大的可扩展的处理能力，而数据库本身也因为硬件的发展能够承受大量的临时表存储数据的需求。这些应用层实现的更高事务隔离级别的应用需求往往比通过数据库实现有更高的灵活性，因此比RC更高的事务隔离级别实际上在我们的大多数应用中已经早就没有人使用了。

可能有朋友要问，为什么MySQL的默认事务隔离级别不是RC而是RR呢？这和MySQL数据库的历史有关，MySQL数据库因为早期的BINLOG复制不支持RAW格式的问题而必须选择RR，如果使用RC无法确保复制数据的一致性。但是用了RR这种事务隔离级别，又会引起数据库的并发性能受到影响，因此MySQL引入了GAP LOCK这种特殊的锁机制，来降低RR对数据库并发的性能影响。哪怕是引入了GAP LOCK，在RR隔离级别下，对于SELECT … FOR UPDATE的操作，RR隔离级别也会比RC有更多的锁阻塞，因此我们建议MySQL用户如果BINLOG复制使用能够RAW的情况下，还是把默认的事务隔离级别设置为RC。

回到文章头上的那个金融交易系统的例子，这个例子是十分典型的RC事务隔离级别就是最佳隔离级别的例子，在此种应用场景下，还把事务隔离级别看作是数据库选型的重要因素，就有点不太合适了。

分布式数据库最早的初衷就是提高并发交易的能力，因此它们在较高事务隔离级别方面天然就处于劣势的，用这种因素去选型，肯定就与选型的初衷背道而驰了。实际上与前面所说的一样，目前我们的应用开发大多数都基于RC事务隔离级别。更高的事务隔离级别的应用需求大多数都在应用中去处理了，或者说哪怕要用数据库来实现，这种应用场景应该也不会是有很高并发的。因此在较高事务隔离级别下测试并发性能对于大多数用户来说确实是没有太大必要了。