MySQL优化MVCC[数据库教程]

  • Z时代
  • 2024-01-10
  • 分类：综合

database

MySQL优化--概述以及索引优化分析

MySQL优化--查询分析工具以及各种锁

七、MVCC

7.1、必备知识

7.1.1、什么是MVCC

多版本并发控制(Multiversion concurrency control， MCC 或 MVCC)，是数据库管理系统常用的一种并发控制，也用于程序设计语言实现事务内存。

mvcc在MySQL的InnoDB引擎中的实现主要是为了提高并发性能，采用更加完善的方式处理读、写之间的冲突，即使有冲突时，也可以做到不加锁，非阻塞并发读

7.1.2、什么是当前读和快照读

  • 当前读

    • 像共享锁、排他锁这些操作都是一种当前读，读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

  • 快照读

    • 像无锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行(serializable)级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

MVCC是为了实现读、写冲突不加锁，而这个读指的就是快照读, 而非当前读

当前读实际上是一种加锁的操作，是悲观锁的实现

7.1.3、MVCC、当前读、快照读之间的关系

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

  • 快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能

  • 快照读本身也是一个抽象概念。MVCC模型在MySQL中的具体实现则是由 3个隐式字段，undo日志 ，Read View 等去完成的

7.1.4、MVCC能解决的问题

数据库并发场景有三种，分别为：

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

  • 读、写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读

  • 写、写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC带来的好处是？

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 所以MVCC可以为数据库解决以下问题

  • 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能

  • 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

7.2、MVCC的实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。

7.2.1、隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段

  • DB_TRX_ID

    6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID

  • DB_ROLL_PTR

    7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

  • DB_ROW_ID

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

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

name

DB_ROW_ID(隐式主键)

DB_TRX_ID(事务ID)

DB_ROLL_PTR(回滚指针)

shimeath

1

1

0x12345656

如上表，DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID，而DB_ROLL_PTR是一个回滚指针，用于配合undo日志，指向上一个旧版本

7.2.2、undo日志

undo_log主要分为两种：

  • insert undo_log

    代表事务在insert新记录时产生的undo_log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

  • update undo log

    事务在进行update或delete时产生的undo_log；不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

purge线程是什么

  • 为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。

  • 为了不影响MVCC的正常工作，purge线程自己也维护了一个read view(这个read view相当于系统中最老活跃事务的read view)；

    • 如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

7.2.3、Read View(读视图)

什么是Read View?

什么是Read View，说白了Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)

所以我们知道 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所在的旧记录就是当前事务能看见的最新老版本

在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。

MySQL优化--MVCC

原文：https://www.cnblogs.com/shimeath/p/13418603.html

以上是 MySQL优化MVCC[数据库教程] 的全部内容， 来源链接： utcz.com/z/535069.html

回到顶部