人阅读

一、说到mvcc就少不了事务隔离级别（大白话解释）

 

序列化（SERIALIZABLE）：事务之间完全隔离，当成一个序列，一个一个执行。

1

可重复读（REPEATABLE READ）：不会被看成一个序列，但是这个事务里发生的改变，另一个事务中是看不到的，即同时执行两个select结果是一样的。（默认）

1

提交读（READ COMMITTED）：这个事务里发生改变并且提交，在另一个事务里是可见的，两条select中间提交过数据，两次结果可能不同。

1

未提交读（READ UNCOMMITTED）：可以读到未提交的数据，容易产生幻读脏读。

1

幻读和脏读：

幻读是每次查询的数据不一样。

脏读是查询到了错误的数据。（查询到结果后有个事务回滚了）

 

二、mvcc

三个隐藏字段

DB_TRX_ID:记录最近更新这条行记录的事务ID，大小为6个字节。

DB_ROLL_PTR:表示指向该行回滚段的指针，innodb便是通过这个指针找到之前的版本数据。该行记录上所有旧版本，在undo中都通过链表的形式组织。

DB_ROW_ID:行标识，如果表没有主键，就会生成一个隐藏的主键。

 

三

MyISAM不支持事务，所以这里就说InnoDB

 

undo log是为了回滚用的。

 

虽然mvcc保证了读是一致的，能解决幻读，但是那是历史数据，并不是真的数据，涉及到的列，我直接锁住，别的事务在这里阻塞。

 

问：那提交读就不锁了吗？ 提交读中没有加间隙锁。但肯定使用了行锁，只有提交之后才能修改

 

事务和锁区别对待：

问：可提交读为啥不能解决幻读，可重复读为啥能解决幻读

 

后者间隙锁

 

仅仅行锁无法保证幻读，除非表锁。 这里说明可提交读如果表锁就能保证幻读。行锁的时候，就无法保证幻读。

 

未提交读 直接读取最新的数据

 

已提交读 每次查询的时候生成一个readview快照

 

可重读读 第一次读的时候生成一个快照，以后的就直接取这个快照

 

串行化：因为加锁，也不存在这个问题

 

几个数据：

当前活跃的事务id们 活跃最小 活跃最大+1（就是下次事务的id） 当前的事务id

 

判断版本：

 

1、如果版本和当前的是事务一样，就说明是当前的事务做的修改，可以直接使用

2、判断是不是小于最小活跃，如果小于，则说明生成readView的时候已经提交了，可以读

3、如果大于等于活跃最大+1,就说明是在这个事务之后开启的，不可见

4、如果是处于活跃列表中，则说明创建readView的时候，不在活跃列表中，就说明当时未提交，继续往前找