事务的隔离级别
| 事务的隔离级别 | 脏读 | 非重复读 | 幻读 |
|---|---|---|---|
| read uncommitted | 可能 | 可能 | 可能 |
| read committed | 不可能 | 可能 | 可能 |
| repeatable read | 不可能 | 不可能 | 可能 |
| serializable | 不可能 | 不可能 | 不可能 |
ANSI/ISO SQL标准定义了4中事务隔离级别：未提交读（read uncommitted），提交读（read committed），重复读（repeatable read），串行读（serializable）。
数据库会面临高并发，肯定也会有性能的考虑，和设计。当然作为持久化落地的部分，保证业务上数据的正确性是最重要的。这当中，当属锁的设计，是数据库最精髓的部分。
事务的隔离级别是数据库层面的设置，会有4个隔离级别，是使用数据库时，对正确性和高并发的一个取舍，隔离界别越高，数据越不会出现准确性问题，相应的并发性越差。反之……
而隔离界别就是通过锁实现的。设置了某个隔离级别时，sql语句就应默认的加锁或者不加锁，这是ISO SQL标准，不同的数据库产品都实现了这个功能。
介绍下相应的隔离级别会带来的问题：
read uncommitted（未提交读）
所有的sql，都没加锁。
事务A读取数据，还没结束时。事务B更新了数据。
导致A读到的是脏数据。所以会有脏读这个名字
read committed（提交读）
提交读，select不加锁，DML语句（update，insert，delete）加锁。
避免了脏读
事务A里先后两次读去到某数据。事务B在两次读取中间时间点更新了此数据。
这种情况会导致事务A两次读的到数据不一致。叫非重复读
repeatable read（重复读）
这个是InnoDB默认的隔离级别
避免了非重复读。
事务A在读取数据，对数据加了行锁（共享锁），事务B不能对该行进行更新操作，但是避免不了insert操作（因为是新加入的行）。这个时候事务A会多读到一行数据。 叫幻读
可以使用MVCC解决这个问题（待再研究）。
serializable（串行读）
这个级别很简单，读加共享锁，写加排他锁，读写互斥（即想要获取写锁，必须所有的锁释放掉才可以）。使用的悲观锁的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发的特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。
不要模式下，select语句是会加锁的！
遗留问题：
有个地方没懂，重复读的隔离级别，是如何控制加锁的？避免非重复读的。感觉跟串行读，差不多。
事务的传播特性
todo
参考文章：
https://www.ibm.com/developerworks/cn/education/opensource/os-cn-spring-trans/
网友评论