事务隔离级别

MySQL 是一个 客户端／服务器 架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每 个客户端与服务器连接上之后，就可以称为一个会话（ Session ）。每个客户端都可以在自己的会话中 向服务器发出请求语句，一个请求语句可能是某个事务的一部分，也就是对于服务器来说可能同时处理 多个事务。事务有 隔离性 的特性，理论上在某个事务 对某个数据进行访问 时，其他事务应该进行 排 队 ，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样对 性能影响太大 ，我们既想保持 事务的隔离性，又想让服务器在处理访问同一数据的多个事务时 性能尽量高些 ，那就看二者如何权衡取舍了。

3.1 数据准备

3.2 数据并发问题

针对事务的隔离性和并发性，我们怎么做取舍呢？先看一下访问相同数据的事务在 不保证串行执行 （也就是执行完一个再执行另一个）的情况下可能会出现哪些问题：

1. 脏写（ Dirty Write ）

对于两个事务 Session A 、 Session B ，如果事务 Session A 修改了 另一个 未提交 事务 Session B 修改过 的数据，那就意味着发生了 脏写

2. 脏读（ Dirty Read ）

对于两个事务 Session A 、 Session B ， Session A 读取 了已经被 Session B 更新 但还 没有被提交 的字段。 之后若 Session B 回滚 ， Session A 读取 的内容就是 临时且无效 的。

Session A 和 Session B 各开启了一个事务， Session B 中的事务先将 studentno 列为 1 的记录的 name 列更新 为' 张三 ' ，然后 Session A 中的事务再去查询这条 studentno 为 1 的记录，如果读到列 name 的值为 ' 张三 ' ，而 Session B中的事务稍后进行了回滚，那么 Session A 中的事务相当于读到了一个不存在的数据，这种现象 就称之为 脏读

3. 不可重复读（ Non-Repeatable Read ）

对于两个事务 Session A 、 Session B ， Session A 读取 了一个字段，然后 Session B 更新 了该字段。 之后 Session A 再次读取 同一个字段， 值就不同 了。那就意味着发生了不可重复读。

我们在 Session B 中提交了几个 隐式事务 （注意是隐式事务，意味着语句结束事务就提交了），这些事务 都修改了studentno 列为 1 的记录的列 name 的值，每次事务提交之后，如果 Session A 中的事务都可以查看 到最新的值，这种现象也被称之为 不可重复读 。

4. 幻读（ Phantom ）

对于两个事务 Session A 、 Session B, Session A 从一个表中 读取 了一个字段 , 然后 Session B 在该表中 插 入 了一些新的行。 之后 , 如果 Session A 再次读取 同一个表 , 就会多出几行。那就意味着发生了幻读。

 

Session A 中的事务先根据条件 studentno > 0 这个条件查询表 student ，得到了 name 列值为 ' 张三 ' 的记录； 之后Session B 中提交了一个 隐式事务 ，该事务向表 student 中插入了一条新记录；之后 Session A 中的事务再根据相同的条件 studentno > 0 查询表 student ，得到的结果集中包含 Session B 中的事务新插入的那条记录，这种现象也被称之为 幻读 。我们把新插入的那些记录称之为 幻影记录 。

数据少了应该算在不可重复读上

幻读是往里边增加数据, 不可重复读是在原有基础上修改数据

 

3.3 SQL中的四种隔离级别

上面介绍了几种并发事务执行过程中可能遇到的一些问题，这些问题有轻重缓急之分，我们给这些问题按照严重性来排一下序：

脏写 > 脏读 > 不可重复读 > 幻读

我们愿意舍弃一部分隔离性来换取一部分性能在这里就体现在：设立一些隔离级别，隔离级别越低，并发问题发生的就越多。 SQL 标准 中设立了 4 个 隔离级别 ：

READ UNCOMMITTED ：读未提交，在该隔离级别，所有事务都可以看到其他未提交事务的执行结 果。不能避免脏读、不可重复读、幻读。

READ COMMITTED ：读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别（但不是MySQL 默认的）。可以避免脏读，但不可重复读、幻读问题仍然存在。

REPEATABLE READ ：可重复读，事务 A 在读到一条数据之后，此时事务 B 对该数据进行了修改并提交，那么事务A 再读该数据，读到的还是原来的内容。可以避免脏读、不可重复读，但幻读问题仍然存在。这是MySQL 的默认隔离级别。

当然在事务A提交之后, 再读这个数据就是事务B修改后的了

SERIALIZABLE ：可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免，但性能十分低下。能避免脏读、不可重复读和幻读。

SQL标准 中规定，针对不同的隔离级别，并发事务可以发生不同严重程度的问题，具体情况如下：

脏写 怎么没涉及到？因为脏写这个问题太严重了，不论是哪种隔离级别，都不允许脏写的情况发生。

不同的隔离级别有不同的现象，并有不同的锁和并发机制，隔离级别越高，数据库的并发性能就越差， 4 种事务隔离级别与并发性能的关系如下：

 

这里要灵活的理解读取的意思，第一次select是读取，第二次的insert其实也属于隐式的读取，只不过是在mysql的机制中读取的，插入数据也是要先读取一下有没有主键冲突才能决定是否执行插入。
幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的select操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些: select某记录是否存在，不存在，准备插入此记录，但执行insert时发现此记录已存在，无法插入，此时就发生了幻读。

在RR隔离级别下，step1、step2是会正常执行的，step3则会报错主键冲突，对于事务1的业务来说是执行失败的，这里事务1就是发生了幻读，因为事务1在step1中读取的数据状态并不能支撑后续的业务操作，事务1:“见鬼了，我刚才读到的结果应该可以支持我这样操作才对啊，为什么现在不可以”。事务1不敢相信的又执行了step4，发现和setp1读取的结果是一样的（RR下的MVCC机制)。此时，幻读无疑已经发生，事务1无论读取多少次，都查不到id= 3的记录，但它的确无法插入这条他通过读取来认定不存在的记录（此数据已被事务2插入)，对于事务1来说，它幻读了。

其实RR也是可以避免幻读的，通过对select 操作手动加行X锁(独占锁) (SELECT ...FOR UPDATE这也正是SERIALIZABLE隔离级别下会隐式为你做的事情)。同时，即便当前记录不存在，比如 id =3 是不存在的，当前事务也会获得一把记录锁(因为InnoDB的行锁锁定的是索引，故记录实体存在与否没关系，存在就加行X锁，不存在就加间隙锁)，其他事务则无法插入此索引的记录，故杜绝了幻读。
在SERIALIZABLE隔离级别下，step1执行时是会隐式的添加行(X)锁/gap(X)锁的，从而step2会被阻塞，step3会正常执行，待事务1提交后，事务2才能继续执行（主键冲突执行失败)，对于事务1来说业务是正确的，成功的阻塞扼杀了扰乱业务的事务2，对于事务1来说他前期读取的结果是可以支撑其后续业务的。