DB之所以设定事务隔离级别,其重要原因就是要避免一些常见的脏数据的读写等问题,根据不同的事务隔离级别,我们能够在数据读写并发效率和数据一致性方面取得不一样的效果;
在具体进入事务隔离级别之前,我们首先来看一下到底哪些情况是我们在DB操作中不希望看到的:
Dirty Read | 脏数据读取 | 比如事务A的未提交(还依然缓存)的数据被事务B读走,如果事务A失败回滚,会导致事务B所读取的的数据是错误的。 |
Non-Repeatable Read | 数据不可重复读取 | 比如事务A中两处读取数据-total-的值。在第一读的时候,total是100,然后事务B就把total的数据改成200,事务A再读一次,结果就发现,total竟然就变成200了,造成事务A数据混乱。 |
Phantom Read | 数据幻想读取 | 和Non-Repeatable Read相似,也是同一个事务中多次读不一致的问题。但是Non-Repeatable Read的不一致是因为他所要取的数据集被改变了(比如total的数据),但是Phantom Read所要读的数据的不一致却不是他所要读的数据集改变,而是他的条件数据集改变。比如Select account.id where account.name="ppgogo*",第一次读去了6个符合条件的id,第二次读取的时候,由于事务b把一个帐号的名字由"dd"改成"ppgogo1",结果取出来了7个数据。 |
接下来,我们来看看标准SQL中到底规范了哪几种事务隔离级别:
Serializable | 全序列化 | 提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。 |
Repeatable Read | 可重复读取 | 禁止不可重复读取和脏读取,但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。 |
Read Committed | 授权读取 | 允许不可重复读取,但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。 |
Read Uncommitted | 未授权读取 | 允许脏读取,但不允许更新丢失。如果一个事务已经开始写数据,则另外一个数据则不允许同时进行写操作,但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。 |
从上表中,我们再总结下,各种事务隔离级别都能避免哪些我们不想看到的事情:
Dirty Read | Non-Repeatable Read | Phantom Read | |
Serializable | N | N | N |
Repeatable Read | N | N | Y |
Read Committed | N | Y | Y |
Read Uncommitted | Y | Y | Y |
隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed,它能够避免脏读取,而且具有较好的并发性能;这也是目前大多数DB的默认事务级别。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁或乐观锁来控制。