read uncommitted: 允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
read committed: 只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
repeatable read: 可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
serializable: 完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
四个级别逐渐增强，每个级别解决一个问题。事务级别越高，性能越差，大多数环境read committed 可以用。
http://www.cnblogs.com/zhoujinyi/p/3437475.html
http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial
http://highscalability.com/blog/2011/2/10/database-isolation-levels-and-their-effects-on-performance-a.html
https://vladmihalcea.com/2014/12/23/a-beginners-guide-to-transaction-isolation-levels-in-enterprise-java/
深入分析事务的隔离级别
The Price of Isolation
The question arises why PostgreSQL, and also SQL Server as well as Oracle® 11g, set Read Committed as default instead of Serializable. The answer is quite simple: complexity of the implementation which imposes a certain amount of overhead and possibly bad performance. The official PostgreSQL 9.1 documentation goes further into detail, but essentially it boils down to real locking, as well as discovering and preventing deadlocks.
有关选择隔离级别的原则
选择哪个隔离级别取决于应用程序执行哪类任务。本节提供了一些有关选择隔离级别的指导。
要选择适当的隔离级别，必须在对一致性和准确性的需求与不受阻碍地执行并发事务的需求之间找到平衡点。如果一个事务只涉及一个表中的一两个特定值，而另一个事务搜索许多大型表并因此可能需要锁定许多行或整个表，且可能需要很长时间才能完成，那么前者对其它进程的干扰通常要比后者少。
例如，如果您的事务涉及在银行帐户间转帐，则必须尽可能地确保返回的信息正确。但是，如果只需要粗略地估计不活动帐户所占的比例，则可能不会介意该事务是否等待其它事务，而且可能愿意牺牲一些准确性，以避免干扰该数据库的其他用户。
此外，转帐可能只会影响包含两个帐户余额的那两行，而要计算不活动帐户的比例则必须读取所有帐户。因此，转帐延迟其它事务的可能性更小。
SQL Anywhere 提供了四个隔离级别：级别 0、1、2 和 3。级别 3 提供完全隔离，并确保以可序列化调度的方式交错执行事务。
如果已为数据库启用了快照隔离，则可以使用三个附加隔离级别：快照、语句快照和只读语句快照。
选择快照隔离级别
快照隔离提供并发和一致性优点。使用快照隔离会增加系统开销，因为正在运行的事务可能需要的旧行版本会一直保存。所以，长时间运行的快照可能需要存储大量旧行版本。通常，用于快照的快照要比用于语句快照的快照持续更长时间。因此，与快照相比，语句快照可能占用更少的存储空间，但一致性较差（事务中的每个语句看到的是不同时间点的数据库）。
大多数情况下，建议使用快照隔离级别，因为它为整个事务提供数据库的单一视图。
语句快照隔离级别提供的一致性较差，但是在由于长时间运行事务而导致临时文件中版本存储所用的空间过大时，它将非常有用。
只读语句快照隔离级别提供的一致性要比语句快照差，但可避免出现更新冲突的可能性。因此，它最适用于移植那些最初打算在不同隔离级别下运行的应用程序。
快照隔离