MYSQL MVCC的实现

MVCC即Multi Version Concurrency Control,在mysql中一条数据会有多个版本,在InnoDb下每一条数据除了我们在DDl语句定义的字段外还隐藏了这三个字段,DATA_TRX_ID(事务Id),DATA_ROLL_PTR(指向undo log上一个版本),DELETE_BIT(删除标志),mysql每个事务的事务Id是递增的

public class TableRowData {
    ....省略DDl语句定义的列
    /**
    *   事务id
    */
    private long dataTrxId;
    /**
    *   指向上一个版本
    */
    private TableRowData dataRollPtr;
    /**
    *   删除标志
    */
    private boolean deleteBit;
}

其实MVCC的实现有点类似于数据结构里的单向链表,每个节点都会有一个指针指向另一个节点;在mysql中是指向上一个版本这样可以在执行事务的时候如果发生异常回滚的话可以直接回滚到上一个版本;在查询的时候会先找到这一行的"数据版本链表"然后for循环链表找到一个当前事务看见的数据版本返回

REPEATABLE READ下的实现

我们在启动一个Mysql可重复读事务的时候会产生一个trx_id并记录当前活跃的事务到一个数组中这里记作"启动时活跃数组",我们将"启动时活跃数组"的最小值记作低水位,将"启动时活跃数组"的最大值记作高水位
如果数据小于低水位的话代表数据是在启动这个事务前已经提交了的,所以在该数据版本是可读的
如果数据在低水位与高水位之间的话且在"当前活跃数据中的话"代表该数据版本是未提交的,所以该数据不可读
如果数据在低水位与高水位之间的话且不在"当前活跃数据中的话"代表该数据版本是以提交的,所以该数据是可读的
如果数据等于trx_id的话代表数据是当前事务产生的,所以该数据是可读的
如果数据大于高水位的话代表数据的事务实在当前事务启动之后启动的,所以该数据不可读

READ COMMIT下的实现

其实repeatable read跟read commit的实现其实是差不多的,不一样的是repeatable read是在事务启动的时候会产生一个"启动时活跃数组",并且在事务里的所有查询都会共用这个"启动时活跃数组"的信息来判断数据版本是否可见,而read commit是在每进行一条语句的时候都会构建一个"启动时活跃数组"在判断数据版本是否可见;

update逻辑

假设我们现在有一个表T,表T的主键是T且只有列K,启动一个事务B,当事务B执行更新一条"id=1 and k = 1"的数据,mysql会读取到这行数据的"数据链表'的"head"的数据来进行更新;
那如果我现在事务B还没提交且还有有另外一个事务C都来更新"id=1 and k =1"的这一行的话岂不是乱套了?答案是不会的,因为有行锁的缘故事务B在更新"id = 1 and k =1"的时候会获取到这一行的数据的行锁,在B没提交的时候C只能等到B提交后再获取"head"来进行更新;select for update跟select share mode也存在这种情况,在查询的时候会查询数据聊表的"head"