MySQL可重复读应用场景_mysql-repeatable read 可重复读隔离级别-幻读实例场景

本文详解 repeatable read 可重复读 隔离级别产生的影响(幻读)

-- SERIALIZABLE serializable 序列化 ；一个个事务排成序列的形式。事务一个挨一个执行，等待前一个事务执行完，后面的事务才可以顺序执行

-- REPEATEABLE READ repeatable read 可重复读；安全上不如serializable，但是性能上比serializable强很多，但会造成幻读。隔离级别：导致幻读，同时开启两个事务，事务A和事务B，当事务A修改了数据，并且提交了，事务B此时查看不到事务A已经提交了的数据，这样保持事务B先后两次查询结果的一致性，当事务B执行update操作的时候，是可以更改事务A提交了的update，insert数据，执行过update操作之后再次select发现数据前后查询不一致！(幻读)

-- READ COMMITED read committed 提交的可读；(oracle默认)

-- READ UNCOMMITED read uncommitted 未提交的可读；(mysql 默认)别的事务可以查看的到使用 当前事务还没提交的 数据；会 脏读，幻读，不可重复读。

-- 幻读：一个事务的查询中查询两次数据，数据不一致！同时开启事务A，事务B。事务A查询一张表中的数据后，事务B修改update了事务A查询的表并做了提交，事务A再次查询这张表，发现数据的不一致！

首先说明：mysql的innodb存储引擎默认的隔离级别就是 repeatable read 可重复读

1.首先开启两个mysql连接，分别开启两个事务A，事务B；两个事务分别查询 software 表的数据，此时数据显示一致的。

1)事务A

2)事务B

3)事务A此时修改了sid = 4 的version ，select 可以查看当前修改的结果，但是还没有提交commit！

4)事务B select * from software;查看software是否有修改，发现没有被修改！

5)事务A，做commit提交；并查看select * from software;

6)事务B,在 5)中事务A做了提交之后，事务B此时是查看不到 事务A对 sid = 4 的version做出的修改的!

7)事务B，执行update software set version = version + 1; 并执行select * from software; 查看，发现出现了幻读。

sid = 4 的 version 是在事务A提交后的结果 version = 44 上进行了 + 1 的操作！

总结：幻读的实现场景：事务B先后查询software表出现的结果，与预想的update 后 version+1 的结果出现了不一致。

另外：事务A，事务B同时对software表的同一条记录做修改，后执行的事务可能会执行失败，此时可能会发生行锁的lock情况，执行不成功。后执行的事务必须等待先执行的事务先commit或者rollback，才能对这同一条要修改的记录作出修改；

如：事务A与事务B同时开启，事务A先对sid = 4 的version做修改update。事务B再修改sid的version

1>事务A，此时事务A还没有作出提交commit。

2>事务B 报错ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

发生了行锁，sid= 4 的记录被事务A锁住了，等待事务A作出提交commit或rollback超时。

3>当事务A作出了commit之后，事务B在执行update如下，就可以成功update了