MVCC和日志

MVCC是一种并发控制的方法，在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存

主要是为了提高数据库并发性能，更好的处理读写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读

• 当前读
  • select lock in share mode(共享锁),select for update;update,insert,delete(排他锁)
  • 读取的是记录的最新版本，读取时要保证其他事务不能修改当前记录，会对读取的记录进行加锁
• 快照读
  • 不加锁的select操作就是快照读，即不加锁的非阻塞的
  • 前提是隔离级别不是串行级别，串行级别下的快照读回退化为当前读
  • 基于提高并发性能的考虑，快照读的实现是基于多版本并发控制
  • mvcc是行锁的一个变种，在很多情况下，避免可加锁操作，降低开销
  • 基于多版本，即快照读可能读到的并不一定是最新数据版本，可能是历史版本

MVCC多版本并发控制指“维持一个数据的多个版本，使得读写操作没有冲突”的概念

MySQL中快照读就是实现MVCC理想模型其中一个非阻塞读功能，相对而言，当前读就是悲观锁的具体功能实现

快照读本身也是抽象概念。MVCC模型在MySQL中实现由3个隐式字段：undo日志，read view等完成

优势

mvcc是用来解决读-写冲突的无锁并发控制，为事务分配单向长时间的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库快照

• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

MVCC+悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突

MVCC+乐观锁：MVCC解决读写重读，乐观锁解决读写冲突

实现原理

Rollback Segments 用来临时保存当数据库发生改变时的先前值

• 因某种原因或其他用户想要通过ROLLBACK声明取消一个数据操作，数据就会复原到之前改变时的值
  • 只在transaction过程中有效，用户执行COMMIT命令，Rollback Segment里面的值就会标识为失效的，数据改变为永久化
• 当有并发session访问一个数据值改变但事务还没有提交的表
  • select语句开始读取一个表同时一个事务也在修改这个表值，修改前的值就保存到Rollback Segment中
  • select语句也是从Rollback Segment里读取表的值

隐式字段

• DB_TRX_ID：6byte，最近修改(update/insert/delete)事务ID；记录创建/最后一次修改该记录的事务ID

• DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本(存储在rollback segment中)

• DB_ROW_ID：6byte，隐含的自增ID(隐藏主键)，如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

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

undo日志

• insert undo log：
  • 代表事务在insert新纪录时产生的undo log
  • 只在事务回滚时需要
  • 在事务提交后立即丢弃
• update undo log：
  • 事务在进行update或delete时产生的undo log
  • 在事务回滚和快照读时需要
  • 不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一删除

purge

• 实现InnoDB的MVCC机制，更新或删除操作都只是设置老记录的deleted_bit，不是真正将过时的记录删除
  • deleted_bit是一个标志位
  • 当执行删除操作时，并不是将记录从数据页中物理删除，而是将deleted_bit设为1，表示记录被删除
  • 更新操作，会创建一个新的记录版本，并将旧记录的deleted_bit设为1，时旧记录类似删除，新纪录包含更新后数据
• 节省磁盘空间，有purge线程来清理deleted_bit为true的记录，同时该线程自己维护一个read view
  • 当记录为true并DB_TRX_ID相对purge线程的read view可见，那么记录被安全清除
  • InnoDB中垃圾回收机制，当确认没有事务需要访问deleted_bit为1记录时，才被物理删除