MVCC多版本并发控制

数据库中的并发分为三种情况：

读读：不存在任何问题，也不需要并发控制

读写：有数据安全问题，脏读，幻读，不可重复读

写写：有数据安全问题，可能存在更新丢失问题

锁是可以解决以上问题的，但是效率低，除了加sync这样的悲观锁，也可以加CAS

MYSQL使用MVCC来提升读写效率。

MVCC多版本并发控制

MVCC(Multi-Version Concurrency Control)即多版本并发控制，用来控制多个线程对数据库中数据的并发访问，在undolog中保存每个记录修改后的版本，读操作只读该事务开始前的数据库的快照。MVCC 可以为数据库解决以下问题：

• 在不加锁的情况下解决读-写，写写冲突，避免了脏读，幻读，不可重复读等事务隔离问题（但不能解决更新丢失问题）
• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能

MVCC 只是一个抽象概念，快照读就是基于MVCC理想模型实现的一个非阻塞读功能，而当前读就是悲观锁的具体实现。

当前读 | 快照读

当前读：读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

select lock in share mode (共享锁), select for update; update; insert; delete (排他锁)

快照读：读取的是记录的历史版本。快照读的实现是基于多版本并发控制，即 MVCC ,可避免了加锁操作，降低了开销，提高了并发访问的性能

不加锁的select

说一下MVCC的实现原理？
答：MVCC的实现原理是依靠记录中的3个隐含字段、undo log日志、Read View来实现的。

3个隐含字段

DB_TRX_ID：当最近修改(修改/插入)事务 ID：记录创建这条记录/最后一次修改该记录的事务 ID,大小为6byte

**DB_ROLL_PTR：**回滚指针,指向这条记录的上一个版本，7byte

**DB_ROW_ID:**隐含的自增ID,如果数据表没有主键，InnoDB 会自动以DB_ROW_ID产生一个聚簇索引

实际还有一个删除 flag 隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除 flag 变了

undo日志
undo log 主要分为两种：

1）insert undo log
代表事务在 insert 新记录时产生的 undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
2）update undo log
事务在进行 update 或 delete 时产生的 undo log ; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清除

purge
为了实现 InnoDB 的 MVCC 机制，更新或者删除操作都只是设置一下老记录的 deleted_bit ，并不真正将过时的记录删除。
为了节省磁盘空间，InnoDB 有专门的 purge 线程来清理 deleted_bit 为 true 的记录。为了不影响 MVCC 的正常工作，purge 线程自己也维护了一个read view（这个 read view 相当于系统中最老活跃事务的 read view ）;如果某个记录的 deleted_bit 为 true ，并且 DB_TRX_ID 相对于 purge 线程的 read view 可见，那么这条记录一定是可以被安全清除的。

实际上对MVCC有帮助的是update undo log,实际存的就是rollback中的旧记录链。

Read View(读视图)
Read view读视图就是在进行快照读时会产生一个read view视图，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)。说白了就是用来记录发生快照读那一刻所有的记录，当你下次就算有执行新的事务记录改变了，read view没变，读出来的数据依然是不变的。

Read VIew主要用来做可见性判断的，当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的 DB_TRX_ID（即当前事务 ID ）取出来，与系统当前其他活跃事务的 ID 去对比（由 Read View 维护），如果 DB_TRX_ID 跟 Read View 的属性做了某些比较，不符合可见性，那就通过 DB_ROLL_PTR 回滚指针去取出 Undo Log 中的 DB_TRX_ID 再比较，即遍历链表的 DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的 DB_TRX_ID , 那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本

版本未提交，不可见
版本已提交，但却是在视图创建后提交的，不可见：如 BC 之于 A
版本已提交，且是在视图创建前提交的，可见

而隔离级别中的RR（可重复读）、和RC（提交读）不同就是差在快照读时
前者创建一个快照和Read View并且下次快照读时使用的还是同一个Read View所以其他事务修改数据对他是不可见的、解决了不可重复读问题。
后者则是每次快照读时都会产生新的快照和Read View、所以就会产生不可重复读问题。

小结一下咯
简而言之，MVCC 就是因为大佬们，不满意只让数据库采用悲观锁这样性能不佳的形式去解决读-写冲突问题，而提出的解决方案，所以在数据库中，因为有了 MVCC，所以我们可以形成两个组合：

MVCC + 悲观锁
MVCC解决读写冲突，悲观锁解决写写冲突
MVCC + 乐观锁
MVCC 解决读写冲突，乐观锁解决写写冲突
这种组合的方式就可以最大程度的提高数据库并发性能，并解决读写冲突，和写写冲突导致的问题。