# MVCC (继续...)

![`smart`](./student-guide/diagram/MVCC01_aa_001_20220511.png)
-------------------------------------------------------------
在 `TiKV` 中的 `RocksDB` 实例中的 3 个 `Column Family` 是这样存储数据的:

1. `Write CF` 中, 由于只有事务1提交了, 所以会有事务1的记录, `key = 1` 和 `key = 2` 两个值的提交记录, `value` 更改都是 `start_ts = 100`. 还有一个 `key = 4` ,我们看他的 `start_ts` 为 80,所以这条记录是以前提交的。

2. `Default CF` 中, 它们是 `key = 1`, `key = 2` 和 `key = 4`, 其中, `key = 1` 和 `key = 2` 的 `start_ts` 是 100, 也就是 `Write CF` 中事务提交的那两行, `key = 4` 的 `start_ts` 为 80。

3. `Lock CF` 中, 由于事务1已经被提交, 所以事务1中 `key = 1`, `key = 2` 的锁就算被删除了, 由于事务2没有提交, 所以事务2中 `key = 1` 和 `key = 4` 的锁还是存在的。

那么, 这些数据以什么顺序存储在 `RocksDB` 中呢, 我们注意以下几点:

1. 对于 `Default CF`, `KEY` 是 `{ user key } + { start_st }`,对于 `Write CF`, `KEY` 是 `{ user key } + { commit_st }`, 对于 `Lock CF`, `KEY` 就是 `{ user key }`。
注:这里的  `{ user key }` 是业务上的键, 而 `KEY` 是指存储在 `RocksDB` 中的键。

2.  所有的 `CF`, 首先, 都是按照 `{ user key }` 的顺序存储的, 其次, 相同 `{ user key }` 的 `KEY` 是按照 `start_ts` 或者 `commit_ts` 由大到小的顺序存储的,这个的原因是让较新的数据（即 `timestamp` 比较大的数据）排列在较老的数据（即 `timestamp` 比较小的数据）前面。

知道了以上内容, 我们就可以理解 `MVCC` 的运作机制了。