TiDB-从0到1-MVCC

在这里插入图片描述
TiDB从0到1系列

TiDB-从0到1-体系结构
TiDB-从0到1-分布式存储
TiDB-从0到1-分布式事务
TiDB-从0到1-MVCC

一、MVCC

Multi-Version Concurrency Control 多版本并发控制，其主要解决了读并发的问题。
其维持一个数据的多个版本使读写操作没有冲突。也就是说数据元素X上的每一个写操作产生X的一个新版本，为X的每一个读操作选择一个版本。由于消除了数据库中数据元素读和写操作的冲突，从而具有更好的性能。特别是对于数据库读和写两种方法，他们不用等待其他同时进行的相同数据写和读的完成。在并发事务中，数据库写只等待正在对同一行数据进行更新的写，这是现有的行级锁的弱点。同时MVCC回收不需要的和长时间不用的内存，防止内存空间的浪费。

在传统关系型数据库中，MVCC的实现方式通常还与事务的隔离级别有关。如MySQL中

RC隔离级别下，事务中可以立即读取到其他事务commit过的readview数据（通过redo产生最新的read view）
RR级别下，事务中从第一次查询开始，生成一个一致性readview，直到事务结束（通过undo历史链表）

二、TiDB中的MVCC

通过判断列簇中是否有主锁决定是否要读历史版本数据。

1、场景

假设test表中现在有三行数据

id：1，name：Tom
id：2，name：Andy
id：4，name：Tony

事务一：

Begin（start_ts=100）
update test set name='Jack' where id=1;
update test set name='Candy' where id=2;
Commit;（commit_ts=110）

事务二：

Begin（start_ts=115）
update test set name='Tim' where id=1;
update test set name='Jerry' where id=4;
未执行Commit；

此时TSO来到120，并分别读取test表中id=1、2、4的数据，TiDB内部是如何处理的呢？

2、数据存储逻辑

首先来看下目前TiKV中数据、锁是什么样了
在这里插入图片描述

可以看到，在默认列簇中存储的是最新的Commit过的数据。
而写列簇中记录了这些数据的start_ts和commit_ts以及主键信息。
在锁列簇中记录了所有（当前、之前）的锁信息。

3、读取数据（id=1）

读取id=1的数据行 （从右向左，依次读取写列簇、锁列簇、默认列簇）
首先在写列簇中找到id=1的最新一条数据，这里主要目的是拿到id=1数据最后一次操作的两个TSO （可能id=1的有很多，之前说过，TiDB中数据的更新都是以插入的形式存在）；
接着去锁列簇中看是否有id=1的相关锁信息：发现确实有一条，在start_ts=115时加的主锁，但是没有锁释放的数据，说明start_ts=115的事务还没有提交。这里也符合我们设立的场景（事务二未提交）。
当找到start_ts=115且没有提交锁信息，最后去默认列簇中找到TSO在115以前，id=1的最新数据 （再次强调可能id=1的有很多，因为TiDB中数据的更新都是以插入的形式存在）
最终读取到id=1的数据，name=Jack。
结果符合预期。
在这里插入图片描述

4、读取数据（id=2）

首先在写列簇中找到id=2的最新一条数据的两个TSO；
接着去锁列簇中看是否有id=2的相关锁信息：发现并没有。
所以直接去默认列簇中找到start_ts=100的id=2的数据即可.
最终读取到id=2的数据，name=Candy。
结果符合预期。
在这里插入图片描述

5、读取数据（id=4）

首先在写列簇中找到id=4的最新一条数据；
接着去锁列簇中看是否有id=4的相关锁信息：发现确实有一条，在start_ts=115时加的跟随锁，但是没有锁释放的数据，说明start_ts=115的事务还没有提交。这里也符合我们设立的场景（事务二未提交）。
当找到start_ts=115且没有提交锁信息，最后去默认列簇中找到TSO在115以前，id=4的最新数据
最终读取到id=4的数据，name=Tony。
结果符合预期。
在这里插入图片描述