MySQL 实战笔记 - 事务隔离和 MVCC

用户头像
shiziwen
关注
发布于: 2020 年 06 月 01 日

这篇文章,总结了《MySQL实战45讲》中的3、8和20节,因为这几篇文章的内容联系比较紧密,所以放在一起做了总结。



事务隔离级别

SQL 标准的事务隔离级别包括:读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(serializable )。

InnoDB默认的隔离级别是可重复读,即一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的。本文的讨论,也是在可重复读隔离级别下。



回滚日志

在 MySQL 中,实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值,通过回滚操作,都可以得到前一个状态的值。也就是说语句更新会生成 undo log(回滚日志)。而这些回滚日志,会当没有事务再需要用到这些回滚日志时被删除,即当系统里没有比这个回滚日志更早的 read-view 的时候。



因此,尽量不要使用长事务,因为长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据,所以这个事务提交之前,数据库里面它可能用到的回滚记录都必须保留,这就会导致大量占用存储空间。



我们应该总是使用set autocommit=1, 通过显式语句的方式来启动事务,避免长事务的发生。



对于一个需要频繁使用事务的业务,可以使用“commit work and chain”来减少语句的交互次数。在 autocommit 为 1 的情况下,用 begin 显式启动的事务,如果执行 commit 则提交事务。如果执行 commit work and chain,则是提交事务并自动启动下一个事务。



MVCC

每一行数据都有多个版本(row),每个版本都有自己的事务ID(row trx_id)。



InnoDB为每一个事务构造了一个数组,保存这个事务的启动瞬间,当前活跃的(未提交)所有事务ID。数组中最小值记为低水位,最大值+1位高水位。



一个事务,能看到某一行的数据哪个版本,是根据这个事务数组来决定的:

按照数据版本从高到低依次查找,只能看到trx_id<低水位的版本,以及trx_id在[低水位, 高水位)中且不在事务数组中的版本。



引用《MySQL实战45讲》的内容来解释一下,“一个数据版本,对于一个事务视图来说,除了自己的更新总是可见以外,有三种情况:

版本未提交,不可见;

版本已提交,但是是在视图创建后提交的,不可见;

版本已提交,而且是在视图创建前提交的,可见。”



这里需要注意一点的是,更新数据都是先读后写的,而这个读,只能读当前的值,称为“当前读”(current read)。而且,除了update语句之外,select语句如果加锁也是当前读,例如lock in share mode 或 for update。



可重复读的核心就是一致性读(consistent read);而事务更新数据的时候,只能用当前读。如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待。



表结构不支持“可重复读”,因为表结构没有对应的行数据,也没有 row trx_id,因此只能遵循当前读的逻辑。



幻读

幻读,指的是一个事务在前后两次查询同一个范围的时候,后一次查询看到了前一次查询没有看到的行。这里需要注意的是,幻读只在“当前读”才会出现,专指“新插入的行”。



产生幻读的原因是,行锁只能锁住行,但是新插入记录这个动作,要更新的是记录之间的“间隙”。因此,为了解决幻读问题,InnoDB 只好引入新的锁,也就是间隙锁 (Gap Lock)。跟间隙锁存在冲突关系的,是“往这个间隙中插入一个记录”这个操作。



间隙锁和行锁合称 next-key lock,每个 next-key lock 是前开后闭区间。



间隙锁和 next-key lock 的引入,帮我们解决了幻读的问题,但同时也带来了一些“困扰”。例如,间隙锁的引入,可能会导致同样的语句锁住更大的范围,这其实是影响了并发度的。由于间隙锁是在可重复读隔离级别下才会生效的,所以如果把隔离级别设置为读提交的话,就没有间隙锁了。但同时,需要解决可能出现的数据和日志不一致问题,需要把 binlog 格式设置为 row。



其实到这里,要深刻理解幻读,还需要理解InnoDB的加锁规则,我会在后面的文章中进行总结。



发布于: 2020 年 06 月 01 日 阅读数: 77
用户头像

shiziwen

关注

还未添加个人签名 2017.11.02 加入

还未添加个人简介

评论

发布
暂无评论
MySQL实战笔记-事务隔离和MVCC