读已提交ReadCommit(不可重复读):每次读取的结果不一样,就是读到最新提交的数据,可能第一次读的是xx,第二次读就是cc了
读已提交 ReatableRead :每次读取的结果都是一样的,分为当前读和快照读,快照读的情况下只能读到之前事务前提交的数据,使用mvcc控制解决了幻读问题
幻读:读到别人准备提交但未提交的事务,但是此时他又回滚了,所以造成像是虚幻读了一样
mvcc解决了并发读写问题,mvcc分为两种场景
快照读:读的时候数据的历史版本--->>select * from xxx
当前读:读的是当前最新版本的--->>>
特殊的读操作,插入/更新/删除操作,属于当前读,需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
MVCC有几个比较重要的概念,三个隐藏字段和readview
RC:每次快照读都会生成readview
RR:只在当前事务第一次快照读的时候生成readriew,而后的快照读都是用第一次快照读生成的readview
MCVV主要依靠undolog多版本控制链和readview来解决并发写读问题,写写的时候还是会加行锁
幻读:是通过间隙锁来解决的,锁定当前id前后的间歇的行数
问题1:当有人在更新数据的时候,其他的事务可以读取这行数据吗?默认情况下需要加锁吗?
答案是:不用。因为默认情况下,有人在更新数据的时候,然后你要去读取这行数据,直接默认就是开启mvcc机制的。也就是说,此时对一行数据的读和写两个操作默认是不会加锁互斥的,因为MySQL设计mvcc机制就是为了解决这个问题,避免频繁加锁互斥
可重复读实现原理
事务ID是递增的。
使用MVCC(多版本并发控制)。InnoDB为每行记录添加了一个事务ID,每当修改数据时,将当事务ID写入。
在读取事务开始时,系统会给事务一个当前版本号(事务ID),事务会读取版本号<=当前版本号的数据,这时就算另一个事务插入一个数据,并立马提交,新插入这条数据的版本号会比读取事务的版本号高,因此读取事务读的数据还是不会变。
MVCC:Snapshot Read vs Current Read
MySQL InnoDB存储引擎,实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注:与MVCC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。MVCC最大的好处,相信也是耳熟能详:读不加锁,读写不冲突。在读多写少的OLTP应用中,读写不冲突是非常重要的,极大的增加了系统的并发性能,这也是为什么现阶段,几乎所有的RDBMS,都支持了MVCC。
在MVCC并发控制中,读操作可以分成两类:快照读 (snapshot read)与当前读 (current read)。快照读,读取的是记录的可见版本 (有可能是历史版本),不用加锁。当前读,读取的是记录的最新版本,并且,当前读返回的记录,都会加上锁,保证其他事务不会再并发修改这条记录。
在一个支持MVCC并发控制的系统中,哪些读操作是快照读?哪些操作又是当前读呢?以MySQL InnoDB为例:
快照读:简单的select操作,属于快照读,不加锁。(当然,也有例外,下面会分析)
select * from table where ?;
当前读:特殊的读操作,插入/更新/删除操作,属于当前读,需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
所有以上的语句,都属于当前读,读取记录的最新版本。并且,读取之后,还需要保证其他并发事务不能修改当前记录,对读取记录加锁。其中,除了第一条语句,对读取记录加S锁 (共享锁)外,其他的操作,都加的是X锁 (排它锁)。
什么是幻读
事务2执行后,在事务1中查询没有查到2添加的数据行,这就是可重复读。
但是,在事务1执行了update后,再查询时就查到了事务2中添加的数据,这就是幻读。
这种结果告诉我们其实在MySQL可重复读的隔离级别中并不是完全解决了幻读的问题,而是解决了读数据情况下的幻读问题。而对于修改的操作依旧存在幻读问题,就是说MVCC对于幻读的解决是不彻底的。