标签：读写 color sql数据库 工程 other 标准 大会 mvc style
事务处理之父Jim Gray对事务隔离性的定义：
Isolation: Concurrently executing transactions see the stored information as if they were running serially (one after another).
1、 脏读(Drity Read)：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。
Read Committed可以解决脏读问题，但仍存在以下两种问题。
2、不可重复读(Non-repeatable read) : 在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这导致锁竞争加剧，影响性能。（另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。待了解。。）
Repeated Read可以解决不可重复读问题和脏读问题，但仍无法解决下面的问题。
3、幻读(Phantom Read) : 在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读仅指由于并发事务增加记录导致的问题，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
MySQL数据库的InnoDB存储引擎是支持事务的引擎，其默认事务隔离级别为REPEATABLE READ（简称RR）。ANSI SQL标准下RR事务隔离级别是Degree 2.9999的隔离性，但是与ANSI SQL标准不同的是，InnoDB存储引擎在RR的事务隔离级别下就解决了幻读问题，从而实现Degree 3的隔离性要求，从而达到了真正隔离性的要求。对比其他数据库，要达到真正的事务隔离性要求，必须将事务隔离级别设置为SERIALIZABLE。换句话说，MySQL InnoDB的默认事务隔离级别可以理解为其他数据库的SERIABLIZABLE级别。
然而，从严格意义上来说，InnoDB的RR事务隔离级别的实现与传统的SERIALIAZABLE事务隔离级别还是有些不一样，这导致在某些特定场景下会给用户有错愕抑或不能接受的感觉，比如唯一索引列在一个事务中允许重复值存在。不过这并不会破坏事务的一致性，只要理解InnoDB存储引擎的锁与MVCC的实现，其实有些怪异的现象都好理解。
SNAPSHOT事务隔离级别
经典的SERIALIAZABLE事务隔离级别采用严格的两阶段锁（strict two-phrase lock，简称：STPL）实现，这也是Jim Gray在书中提及的方法。但是由于读写都需要上锁，这样导致在大部分情况下事务的性能都不如类似RC（READ COMMITTED）这样的事务隔离级别。
为了解决性能问题，最近越来越多的数据库开始支持SNAPSHOT事务隔离级别(简称SI)，如Oracle、PostgreSQL、Microsoft SQL Server数据库等。SI事务隔离级别貌似解决了Dirty Read、Unrepeatable Read和Phantom Read问题。可惜的是，其依然不符合真正隔离性的要求，其存在write skew的异常问题。2008年的SIGMOD大会上，有人提出了Serializable Snapshot Isolation（SSI），从而解决了之前SI事务隔离级别存在的问题。PostgreSQL9.1版本在此论文基础上实现了SSI事务隔离级别并做了相应的优化。此外，在2012年的VLDB大会上PostgreSQL发布了相应的论文，有兴趣的读者可以继续研究。
基于快照的事务隔离级别（不论SI还是SSI）性能较之经典的SERIALIZABLE事务隔离级别提升非常多，但其存在两个问题不容忽视。一是其会导致“错误”的回滚，因为其策略就是保证正确，虽然有时可能会误杀一些没有问题的事务。二是对于大事务的支持需要额外的内存保证，如果修改的数据量特别大，那么这可能会导致内存溢出的问题发生。但不论怎么说，SSI可能都是未来的一个默认事务隔离级别发展的方向。期待MySQL数据库也能尽快支持。
标签：读写 color sql数据库 工程 other 标准 大会 mvc style
原文地址：http://www.cnblogs.com/ws-astrologer/p/6681089.html
