MySQL事务中MVCC和锁机制共同作用的分析

    大家一定都可以单独理解MVCC和锁机制，但是当在一个事务中在MVCC下使用加锁语句后，MySQL的查询语句是怎么处理的呢？

​    这个问题一直困扰我很久，久久不能释怀，这里我做了一个实验，得出了结论：

• 1、MVCC和锁机制是互不干扰的，当我们在事务中对记录使用了加锁操作，并不会影响我们后面使用快照读（普通SELECT）走MVCC（即即使当前读和快照读的数据不一致，也不会把快照读的数据刷新到MVCC中改变快照读的数据）。
• 2、在一个事务中，UPDATE、DELETE语句会修改最新记录上的最后操作事务ID值，而SELECT语句，不管是SELECT FOR SHARE还是SELECT FOR UPDATE都不会修改最新记录上的最后操作事务ID值。

这样听起来有点抽象，所以以下使用演示的方式：

• 验证1的正确性：

总结：结合6和7的结果，可以看出即使使用了当前读select for update加锁操作（不会修改记录的最新修改事务ID），后面的快照读select语句依旧走的是MVCC，导致当前读和加锁读的数据是不一样的，没有把我们前面的当前读缓存下来或者说更新到MVCC中去。

• 验证2的正确性：

总结：结合8、9、10（图片标错了）可以得出，8的update语句不仅修改了记录的值，还修改了记录上的最新修改事务的ID值，所以快照读select语句走MVCC得到的数据 和 当前都select for update语句得到的数据是一样的。