多版本并发MVCC

事务隔离级别

SQL标准的事务隔离级别包括：

• 读未提交 （read uncommitted） ：一个事务还没提交时，它做的变更就能被别的事务看到。
• 读提交 （read committed） ：一个事务提交之后，它做的变更才会被其他事务看到。
• 可重复读 （repeatable read） ：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据时一致的。当然可重复读隔离级别下，未提交变更对其他事务也是不可见的。
• 可串行化（serializable）： 对同一行记录，当出现不同事物的读写冲突时，是通过串行化的方式解决的， “写”会加“写锁”，“读”会加“读锁” ，后一个事务必须等前一个事务完成才能执行。

不同隔离级别能够解决不同的隔离性问题 ：

隔离级别	脏读可能性	不可重复读可能性	幻读可能性
读未提交	可能	可能	可能
读已提交	不可能	可能	可能
可重复读	不可能	不可能	可能
可串行化	不可能	不可能	不可能

【注】 标准的可重复读隔离性级别，有幻读的可能性。但是，Innodb在可重复读级别下，使用了 next-key lock （行锁 + 间隙锁）解决了幻读问题。 间隙锁就是对值的间隙范围加锁，防止新的记录插入。 https://zhuanlan.zhihu.com/p/109129926

作用

InnoDB中，实现了两种标准的行级锁：共享锁、排它锁。

普通的select不会对行上锁，而select…lock in share mode会上共享锁，select…for update会上排它锁。

• 对于普通的select的读取方式，称为快照读，也叫一致性非锁定读。
• 对于带锁的select读取，或者update tb set a = a+1（读取a的当前值），称为当前读，也叫一致性锁定读。

为了能在 update 锁定的同时进行select，提高并发性，引入了MVCC（多版本并发控制）。

实现

所谓多版本，就是一行记录在数据库中存储了多个版本，每个版本以事务ID作为版本号。InnoDB 里面每个事务有一个唯一的事务 ID，是在事务开始的时候向InnoDB的事务系统申请的，并且按照申请顺序严格递增的。假如一行记录被多个事务更新，那么，就会产生多个版本的记录（ 版本号：trx_id ），不同版本记录可以用链表链接。

在每个记录多版本的基础上，需要利用一致性视图，来做版本的可见性判断。

一致性视图主要是支持InnoDB在“读已提交”和“可重复读”级别的并发访问。

• “读未提及”级别下，没有一致性视图
• “读已提交”级别下，会在 每个SQL开始执行的时候 创建一致性视图
• “可重复读”级别下，会在 每个事务开始的时候 创建一致性视图
• “可串行化”级别下，直接通过加锁避免并发问题

ReadView中主要包含4个比较重要的内容：

• m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
• min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
• max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。
• creator_trx_id：表示生成该ReadView的事务的事务id。

有了一致性视图后，我们就可以判断一行数据的多版本可见性了，无论是“读已提交”还是“可重复读”级别，可见性判断规则是一样的，区别在于创建快照（一致性视图）的时间。

在当前事务中，读取某一行的记录及其记录，其可见性判断有五种情况：

• 如果版本号小于“低水位”（min_trx_id），说明事务已经提交，可见；
• 如果版本号大于“高水位”（max_trx_id），说明这行数据的这个事务id版本是在快照后产生的，不可见；
• 如果版本号在m_ids数组中，说明这个事务还没提交，不可见；
• 如果版本号不在m_ids数组中，且低于高水位，说明这个事务已经提交，可见；
• 如果版本号等于creator_trx_id， 意味着当前事务在访问它自己修改过的记录，可见。

【注】仅适用于select快照读，不适用于update当前读，当前读需读取记录的最新版本。

概括

每个事务在创建时被赋予唯一的版本号（递增）。当记录被事务更新时，会附带上对应的版本号，一条记录可能有多个版本。MVCC利用这些事务版本号创建一致性视图，判断数据的可见性，实现并发读。

参考：

https://zhuanlan.zhihu.com/p/118658549

https://www.cnblogs.com/luozhiyun/p/11216287.html