mvcc清晰易懂版本，搞清这张图，mvcc就懂了。

搞懂这个图就可以了

mvcc核心4个东西（这些都是事务字段和readview的东西，看完下面，这个就懂了，一开头看这四个东西，很容易懵逼）

• 1、事务版本号

• 2、表的隐藏列。

• 3、undo log

• 4、 read view

事务的版本号：每次开启都会获得自增长的事务id，可以根据事务的id判断，事务的执行顺序，它是自增的，有点像主键。

表的隐藏列：会为我们添加三个隐藏字段

• DB_TRX_ID: 事务ID，记录的是当前事务在做INSERT或UPDATE语句操作时的事务ID；

• DB_ROLL_PTR：指向上一个版本数据在undo log 里的位置指针，回滚指针，通过它可以将不同的版本串联起来，形成版本链。；

• DB_ROW_ID: 隐藏ID ，当创建表没有合适的索引作为聚集索引时，会用该隐藏ID创建聚集索引;

结合上图可以看到，DB_TRX_ID，DB_ROLL_PTR，这两个东西用到了让事务指向了undolog

假如说有个新数据要修改，把张三改成李四，可以看到事务id变成了104（有点像主键自增长1），上个版本数据的行号变为了103

比如李四的事务表：它的DB_ROLL_PTR就变为了103

read view 就是没有提交的事务有哪些，就是一个整体的事务的状态表，每次事务开启都有一个readview。

我的理解，read view 是这样的，先给你们看看原本比较笼统的说法。

Read view 的几个重要属性

• trx_ids: 当前系统活跃(未提交)事务版本号集合。

• low_limit_id: 创建当前read view 时“当前系统最大事务版本号+1”。

• up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号”

• creator_trx_id: 创建当前read view的事务版本号；

• 

我的理解的read view（不官方版本），就是一个数据快照，看还有哪些事务没有提交，可能有错误。

trx_ids：就是当前有哪些事务还没有提交，比如上图，a，b双方都有id，但是都没提交，那么它们就是一个集合，根据他们的事务id就是102,103.

low_limit_id:事务id大于low_limit_id，说明它是在创建read view之后创建的，那么肯定是没有提交过的，所以数据不显示。

up_limit_id:当前的的事务id小于up_limit_id。以下可能有错误，说明事务已经提交过?所以它的的数据是可以显示的。

ps：可能有种情况，事务id在low_limit_id和up_limit_id之间，则说明刚刚创建没多久的事务还没有提交的事务，所以要在trx_ids中匹配，没有的话，说明已经提交了，数据不显示。存在，只有自己能看到，别人不能看见，因为这是自己创建的事务。

 creator_trx_id：这东西似乎是用来区别是不是自己生成的事务，一般来说是最新的那个事务id，可以看第一张图，另外一个查询的人，生成了事务id，说明是根据最后一个开启事务id，它就是 creator_trx_id。

ps：说明如果事务id，不和 creator_trx_id相等，说明这是外星球来的人，不是自己人。

补充：mvcc只在读已提交读未提交中使用