我要评论1.mvcc简介
1.1mvcc定义
mvcc(multi version concurrency control)，多版本并发控制，是一种数据库的并发控制机制。它用于管理事务并发执行时对数据的访问和修改，保证在多个事务同时对数据库进行读写操作，不会出现数据不一致或丢失的情况
1.2mvcc解决的问题
当多个事务同时访问数据库中的相同数据时，可能会有几种情况：
- 读：多个事务都是读操作，不会产生并发问题
- 读+写：事务有读有写，那么会产生脏读、不可重复读、幻读的问题
- 写：多个事务同时写，可能会产生数据丢失、覆盖等问题
针对以上问题，在读+写的情况下，通常需要加锁来解决问题，mysql的innodb实现了mvcc来更好的处理读写冲突，做到不用加锁，实现非阻塞并发读
在都是写操作的情况下，只能通过加锁的方式解决。
1.3当前读与快照读
当前读：读取的是最新版本的数据，保证读取时不会有其他事务修改数据，需要对记录加锁
加共享锁，读不受影响，写会被阻塞
select ... lock in share mode;
加排他锁，读和写都被阻塞（快照读不受影响）
select ... for update;
更新、插入、删除操作以及串行化隔离级别都是当前读
快照读：每一次修改数据，都会在undolog中存有原始记录（快照），快照读就是读取某一版本的记录。这种方式能够不加锁读数据，但是可能会读到旧的数据。一般的查询都是快照读
select * from tablename;
2.mvcc原理
mvcc主要通过行记录中的隐藏字段、undolog和readview实现的
2.1隐藏字段
mysql的innodb引擎中，在每一行记录中除了自定义的字段，还有3个隐藏的字段（innodb引擎）
- row_id：如果表没有自定义主键，那么会自动生成row_id作为主键
- trx_id：记录修改、新增这条记录的事务id
- roll_pointer：回滚指针，指向当前记录的上一个版本
2.2版本链
在修改数据时，mysql会向undolog中记录数据原来的快照，用于进行回滚操作。undolog还能用来实现mvcc
如以下例子，mvcc生成版本链：
当事务1001（trx_id=1001）执行了 insert into user values(1,'竹子',23) 之后：
当事务1002（trx_id=1002）执行了 update user set name='竹笋' where id=1 之后：
当事务1003（trx_id=1003）执行了 update user set name='竹叶' where id=1 之后：
可以看到，不同版本的数据被指针连接起来形成了一个链表。
当我们要读取时，如何判断该读取哪个版本呢？这就与生成的读视图有关了。
2.3readview
读视图用于决定事务可以读到哪个版本的数据
它包含以下主要信息：
- trx_ids：当前mysql中所有活跃的事务id集合（没提交或回滚的事务集）
- low_limit_id：当前出现的最大的事务id+1，表示下一个要分配的事务id
- up_limit_id：当前活跃的事务id集合中，最小的事务id
- creator_trx_id：生成该readview视图的事务的id
mysql5.7版本的源码对于这些信息的定义如下：
插入一个注意事项：🐭🐮🐯🐰🐉🐍🐴🐑🐒🐔🐶🐷
start transaction不代表立即生成readview，而是在事务中第一次快照读的时候生成readview，具体参考mysql可重复读隔离级别下开启事务的一个注意事项
想要开启事务时就生成readview，请使用：
start transaction with consistent snapshot;
2.4读视图生成原则
readview定义了一个可见性算法，当事务进行快照读时，依据该算法判断事务能够读取哪个快照。
源码的可见性判断逻辑如下：(下载源码可访问：官网，操作系统选择source code)
/** check whether the changes by id are visible.
@param[in] id transaction id to check against the view
@param[in] name table name
@return whether the view sees the modifications of id. */
//判断某个版本的数据是否对当前事务可见
bool changes_visible(
trx_id_t id,
const table_name_t& name) const
my_attribute((warn_unused_result)) {
ut_ad(id > 0);
//快照的id小于活跃事务id集合中的最小事务id 或者 快照的id等于创建这个视图的事务id
if (id < m_up_limit_id || id == m_creator_trx_id) {
return(true);
}
//检查快照id是否合法，如果快照的id大于等于下一要分配的事务id，则需要抛出警告信息（会出现这种情况吗？）
check_trx_id_sanity(id, name);
//快照的id大于等于下一要分配的事务id
if (id >= m_low_limit_id) {
return(false);
}
//当前不存在活跃的事务
else if (m_ids.empty()) {
return(true);
}
const ids_t::value_type* p = m_ids.data();
//通过二分查找判断快照id是否在活跃事务集合中，存在则快照不可见，不存在则快照可见
return(!std::binary_search(p, p + m_ids.size(), id));
}
- 当快照id等于当前事务id时（trx_id=creator_trx_id），说明该版本是当前事务修改的，该快照对当前事务可见
- 当快照id小于活跃事务的最小id（trx_id<up_limit_id），说明该版本对应的事务已经提交了，该快照对当前事务可见
- 当快照id大于等于下一个要分配的事务id（trx_id>=low_limit_id），则该快照对当前事务不可见
- 当快照id小于下一个要分配的事务id并且活跃事务id数量为0（trx_id<low_limit_id && trx_ids.size==0），则该快照对当前事务可见
- 当以上条件都不满足，则在活跃事务id集合里查找快照id，如果不存在，则可见，否则不可见
3.rc和rr隔离级别下mvcc的不同
mvcc主要用来解决rc（读已提交）隔离级别下的脏读和rr（可重复读）隔离级别的不可重复读问题，所以mvcc只在rc和rr隔离级别下生效。
区别在于，rc级别下，每一次快照读都会生成一个最新的readview；rr级别下，只有事务中的第一次快照读会生成readview，之后的快照读会使用第一次生成的readview。
事务能否查询到其他事物修改的数据，取决于readview，而rc和rr两个级别的readview生成方式不同，就导致了事务可见性不同。（rc级别下一个事务可以查询到其他事物在此期间修改并提交的数据，因为它的每次查询都会生成新的readview；rr级别下事务无法查询到其他事物在此期间修改并提交的数据，因为他的readview只在第一次快照读生成）
到此这篇关于mysql多版本并发控制mvcc原理浅析的文章就介绍到这了,更多相关mysql多版本并发控制mvcc内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论