MVCC 过程中会加锁吗？

MVCC 机制，全称（Multi-Version Concurrency Control）多版本并发控制，是确保

在高并发下， 多个事务读取数据时不加锁也可以多次读取相同的值。 MVCC 在读已提交（READ COMMITTED）、可重复读（REPEATABLE READ 简称 RR）模式下才生效。MVCC 在可重复读的事物隔离级别下，可以解决脏读、脏写、不可重复读等问题。 我们知道，MVCC 是基于乐观锁的实现，所以很自然的想到 MVCC 是不是不会加锁。 这个问题也要看情况来回答

一般情况

在 MVCC 中，通常不需要加锁来控制并发访问。相反，每个事务都可以读取已提交的快照，而不需要获得共享锁或排它锁。在写操作的时候，MVCC 会使用一种叫为“写时复制”（Copy-On-Write）的技术，也就是在修改数据之前先将数据复制一份，从而创建一个新的快照。当一个事务需要修改数据时，MVCC 会首先检查修改数据的快照版本号是否与该事务的快照版本一致，如果一致则表示可以修改这条数据，否则该事务需要等待其他事务完成对该数据的修改。另外，这个事物在新快照之上修改的结果，不会影响原始数据，其他事务可以继续读取原始数据的快照，从而解决了脏读、不可重复度问题。所以，正是有了 MVCC 机制，让多个事务对同一条数据进行读写时，不需要加锁也不会出现读写冲突。

特殊情况

MVCC 本身是为了解决读写冲突，避免阻塞，所以理论上 MVCC 在存取数据时并不存在加锁的操作。但是在实际的数据库操作中，MVCC 并不能完全无视锁机制。这是因为虽然 MVCC 可以解决读写冲突，增强并发性，但在某些场景下还是需要用到锁来控制并发，比如更新操作。在 MVCC 中，对一个数据进行更新操作，通常会先对这个数据加锁，防止其他的事务对同一个数据进行修改，以保证数据的一致性。然后在这个事务持有锁的期间，其他的事务如果要对同一个数据进行读取，它可以读取这个数据的旧版本，不会被阻塞。

总结

所以说，MVCC 在处理过程中，虽然本身不涉及加锁，但在实际操作中，为了防止更新操作导致的数据不一致，会加锁，但对读操作是非阻塞的。