MySQL优化--概述以及索引优化分析
MySQL优化--查询分析工具以及各种锁
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:记录创建这条记录/最后一次修改该记录的事务IDDB_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