转自CSDN - http://blog.csdn.net/f8152/article/details/53165317
数据隔离级别分为不同的四种：
1. SERIALIZABLE 可序列化
最严格的级别，事务串行执行，资源消耗最大；
2. REPEATABLE READ 可重复读
InnoDB的默认级别。保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
3. READ COMMITTED 提交读
大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
对该事务隔离级别而言，从数据库理论的角度来看，其实违反了事务ACID中I的特性，即隔离性。
4. READ UNCOMMITED 未提交读
保证了读取过程中不会读取到非法数据。
一个对照关系表
| Dirty reads | non-repeatable reads | phantom reads | |
|---|---|---|---|
| SERIALIZABLE | 不会 | 不会 | 不会 |
| REPEATABLE READ | 不会 | 不会 | 会 |
| READ COMMITTED | 不会 | 会 | 会 |
| READ UNCOMMITED | 会 | 会 | 会 |
上面的解释其实每个定义都有一些拗口，其中涉及到几个术语：脏读、不可重复读、幻读。
这里解释一下：
脏读
读到了别的事务回滚前的脏数据。比如事务B执行过程中修改了数据X，在未提交前，事务A读取了X，而事务B却回滚了，这样事务A就形成了脏读。
不可重复读
比如事务A首先读取了一条数据，然后执行逻辑的时候，事务B将这条数据改变了，然后事务A再次读取的时候，发现数据不匹配了，数据前后不一致，就是所谓的不可重复读了。
幻读
事务A首先根据条件索引得到10条数据，然后事务B改变了数据库一条数据，导致也符合事务A当时的搜索条件，这样事务A再次搜索发现有11条数据了，就产生了幻读。
幻读的一个例子：
事务A开启事务（在mysql 可重复读的隔离级别下）
事务A读取表1有30行数据，
事务B对表1插入了一条数据
事务A再次读取表1的数据还是30行（A心想，好！绝对不会错的，就是要更新这30条）
事务A进行了更新操作（这里一定是要对全表的更新操作，单行数据的操作不会出现幻读的）
事务A再次查表1数据，想看看自己劳动的成果事务
A：MMP，这多出来的一条数据是哪里来的，而且还被我更新了，我TM只想更新前30条的啊。(好怕怕，我是不是中了幻术)
(买了个苹果手机 - https://www.zhihu.com/question/47007926/answer/175397934)
幻读的另一个例子：
# users： id 主键
1、T1：select * from users where id = 1;
2、T2：insert into `users`(`id`, `name`) values (1, 'big cat');
3、T1：insert into `users`(`id`, `name`) values (1, 'big cat');
T1 ：主事务，检测表中是否有 id 为 1 的记录，没有则插入，这是我们期望的正常业务逻辑。
T2 ：干扰事务，目的在于扰乱 T1 的正常的事务执行。
在 RR 隔离级别下，1、2 是会正常执行的，3 则会报错主键冲突，对于 T1 的业务来说是执行失败的，这里 T1 就是发生了幻读，因为T1读取的数据状态并不能支持他的下一步的业务，见鬼了一样。
在 Serializable 隔离级别下，1 执行时是会隐式的添加 gap 共享锁的，从而 2 会被阻塞，3 会正常执行，对于 T1 来说业务是正确的，成功的扼杀了扰乱业务的T2，对于T1来说他读取的状态是可以拿来支持业务的。
(https://www.zhihu.com/question/47007926/answer/222348887)
InnoDB如何避免幻读呢？
InnoDB提供了next-key locking算法可以避免幻读，但需要应用程序自己去加读锁，即
SELECT xxx FOR READ 或 LOCK IN SHARE MODE
使用索引时，加的是查找范围内的行级锁。否则是表级别的锁。
SELECT * FROM child WHERE id > 100 FOR UPDATE;
# 这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。
InnoDB的多版本并发控制（Multi Version Concurrency Control，MVCC）
一致性的非锁定行读（consistent nonlocking read，简称CNR）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中运行的数据。如果读取的行正在执行delete、update操作，这时读取操作不会因此而会等待行上锁的释放，相反，InnoDB存储引擎会去读取行的一个快照数据。
非锁定读，是因为不需要等待访问的行上X锁的释放，快照数据是指该行之前版本的数据，该实现是通过Undo段来实现，而Undo用来在事务中回滚数据，因此快照本身是没有额外的开销，此外读取快照是不需要上锁的，因为没有必要对历史的数据进行修改。
非锁定读大大提高了数据读取的并发性，在InnoDB存储引擎默认设置下，这是默认的读取方式，既读取不会占用和等待表上的锁。但是不同事务隔离级别下，读取的方式不同，不是每一个事务隔离级别下的都是一致性读。同样，即使都是使用一致性读，但是对于快照数据的定义也不相同。
快照数据其实就是当前数据之前的历史版本，可能有多个版本。如上图所示，一个行可能不止有一个快照数据。我们称这种技术为行多版本技术。由此带来的并发控制，称之为多版本并发控制（Multi Version Concurrency Control，MVCC）。
在Read Committed和Repeatable Read模式下，innodb存储引擎使用默认的非锁定一致读。在Read Committed隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据；而在Repeatable Read隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。
(https://www.linuxidc.com/Linux/2014-11/108860p4.htm)
LOCK IN SHARE MODE 和 SELECT FOR UPDATE
这两个语句是在事务内起作用的，所涉及的概念是行锁。它们能够保证当前session事务所锁定的行不会被其他session所修改(这里的修改指更新或者删除)。
两个语句不同的是，一个是加了共享锁而另外一个是加了排它锁。
共享锁允许普通读取和其他事务加共享锁读取，但是不允许其他事务加排它锁和修改。
排它锁允许普通读取，但不允许其他事务加共享锁或者排它锁，更不允许其他事务修改。
注意死锁
使用lock in share mode具有很高的风险，看下面的案例：
T1: A加共享锁
T2: B加共享锁
T1: A进行UPDATE（因为B的锁阻塞）
T2: B进行UPDATE（因为A的锁阻塞）
这个时候mysql检测到会发生死锁，会中断当前事务该语句的执行，T2中断，然后开启一个新的事务
这个时候T1可以执行成功了
可以看出使用lock in share mode比较危险，很可能因为其他session同时加了这种锁，导致当前session无法进行更新，进而阻塞住。
使用select for update的时候，如果锁定当前行的事务一直不退出，将会导致其他进行这个行更改操作的session一直阻塞。
因此，无论在使用select lock in share mode 或者 select for update，都应该尽快释放锁。
