数据库学习测试案例-20240329-mysql数据库隔离级详细分析MVCC READ VIEW等解析_mysql readview例子

     在数据库的世界里，MySQL以其出色的性能与稳定性备受青睐。今天，让我们一同走进MySQL的神秘世界，探寻其中四种隔离级别的奥秘。 首先，我们需要了解一个概念——事务隔离。

简单来说，在并发访问数据库的情况下，为了保证数据的一致性和避免脏读、幻影读等问题，就需要对事务进行一定程度上的限制，这就是事务隔离。而MySQL中的四种隔离级别，则是对这些问题的不同解决方案，

事务的隔离级别的提出就是为了修复事务在并发的情况下读数据所发生的各种问题。

• 为了修复脏读的问题，我们提出了读已提交的事务隔离级别；
• 为了修复不可重复的问题，我们提出了可重复读事务隔离级别；
• 为了修复幻读的问题，我们提出了串行化的事务隔离级别。

注意：在MySQL中，修复幻读的时候，并没有使用到串行化的事务隔离级别，而是使用了MVCC多版本并发控制和Next key lock临键锁的方式来修复幻读问题的。

一、读未提交（ReadUncommitted）

   读未提交是指在一个事务中，可以读取到其他事务尚未提交的数据。这种隔离级别允许“脏读”，即读取到其他事务未完成处理的数据。虽然可能存在数据不一致的问题，但是它的执行效率较高。

二、读已提交（Read Committed）

相较于读未提交，“读已提交”则是在一个事务中，只能读取到其他事务已经提交的数据。这意味着在同一事务内的查询操作将无法看到该事务开始后其他会话所做的更改。这是一种较为常见的隔离级别，有效地防止了脏读的发生，但在特定情况下仍可能出现不可重复读和幻影读问题。

三、可重复读（Repeatable Read）

可重复读顾名思义，就是在同一事务内多次执行相同的查询语句，得到的结果相同，即使在这之间已有其他事务进行了修改操作。此隔离级别有效地解决了不可重复读的问题，然而幻影读现象仍然可能发生。

四、 串行化（Serializable）

作为最高级的隔离级别，串行化不仅实现了前面三种隔离级别所能解决的所有问题，还消除了幻影读的现象。它确保了所有事务如同顺序执行一样，既不会产生脏读，也不会出现不可重复读和幻影读情况。但代价便是牺牲了一定的并行性，可能导致系统资源利用率降低。 这四大隔离级别各具特色，针对不同的业务场景有着各自的优劣。选择适合自己的那一款，方能游刃有余地驰骋于数据库这片广袤的土地上。希望本文能让大家对MySQL隔离级别有一个更深入全面的认识，并能在实际工作中灵活运用。

五、MVCC

MVCC全称Multi-Version Concurrency Control，即多版本并发控制。它是一种并发控制的方法，它可以维护一个数据的多个版本，用更好的方式去处理读写冲突，做到即使有读写冲突也能不加锁，依赖undo表空间。

当有多个并发事务操作一行数据时，对这行数据的修改会产生多个版本，多个版本通过上述的一个隐藏字段DB_ROLL_PTR回滚指针指向Undo Log数据地址形成一个链表，即MVCC版本链。

六、ReadView读视图

ReadView读视图是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。

上面讲过Undo Log和MVCC版本链，一条数据经过多次修改会产生多个版本，而快照读是根据不同时机创建的快照获取数据的，那么快照读SQL在执行时该读取那个版本的数据就是靠ReadViw读视图来决定的。

ReadView读视图中包含了四个核心字段，也是读取数据的判断依据：

ReadView一共有四种匹配规则：

五、 当前读

当前读读取的是记录的最新版本。同时在读取的时候还要保证其他的并发事务不能更改当前记录，那么当前读会对它要读取的记录进行加锁。不同的操作会加上不同类型的锁，如：SELECT ... LOCK IN SHARE MODE(共享锁)，SELECT ... FOR UPDATE、UPDATE、INSERT、 DELETE(排他锁)。

当前读的时候，是需要读取数据库中最新的数据内容。所谓最新的数据内容是修改且已经提交的数据。

六、 快照读

简单的不加锁的SELECT就是快照读，快照读读取的是快照生成时的数据，不一定是最新的数据，它是不加锁的非阻塞读。而不同隔离级别下，创建快照的时机也不同：

• READ-COMMITTED(读已提交)：事务每次SELECT时创建ReadView

• REPEATABLE-READ(可重复读)：事务第一次SELECT时创建ReadView，后续一直使用

在MySQL默认隔离级别(REPEATABLE-READ)下，快照读保证了数据的可重复读。

      我们在前面提到了快照读。所谓的快照读是指，在一个事务执行的过程，在这个事务当中执行一些普通的查询，这些查询没有什么特殊的用法，只是为了获取某些数据行的结果，这样的查询就是快照读。快照读在获取数据行的时候，是从一致性视图中获取数据的，目的是为了满足在事务运行期间对数据的可重复性读的要求，在一致性视图中的数据，是在事务启动的时候就已经创建好的，它里面的值将贯穿整个事务运行期间所有的快照读。

七、幻读

  幻读就是事务A首先根据条件索引得到N条数据，然后事务B改变了这N条数据之外的M条或者增添了M条符合事务A搜索条件的数据，导致事务A再次搜索发现有N+M条数据了，这就会产生幻读。

• 通过 next-key lock解决。

• 产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读，InnoDB引入间隙锁。

• Gap lock间隙锁在可重复读级别下才有效

• 间隙锁和行锁合称 next-key lock，每个 next-key lock 是前开后闭区间。

在数据库定义的四种隔离级别中

最高隔离级别SERIALIZABLE_READ可以保证不出现幻读的问题。

Repeatable Read (RR)

针对当前读，RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，不存在幻读现象。

八、不可重复读

     是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。 

Mysql数据库事务隔离级别
SQL 标准定义了四个隔离级别：

READ-UNCOMMITTED(读取未提交)： 事务的修改，即使没有提交，对其他事务也都是可见的。事务能够读取未提交的数据，这种情况称为脏读。
READ-COMMITTED(读取已提交)： 事务读取已提交的数据，大多数数据库的默认隔离级别。当一个事务在执行过程中，数据被另外一个事务修改，造成本次事务前后读取的信息不一样，这种情况称为不可重复读。
REPEATABLE-READ(可重复读)： 这个级别是MySQL的默认隔离级别，它解决了脏读的问题，同时也保证了同一个事务多次读取同样的记录是一致的，但这个级别还是会出现幻读的情况。幻读是指当一个事务A读取某一个范围的数据时，另一个事务B在这个范围插入行，A事务再次读取这个范围的数据时，会产生幻读
SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC（多版本并发控制），通过保存修改的旧版本信息来支持并发一致性读和回滚等特性。

ACID：
原子性：undo log（MVCC）
一致性: 最核心和最本质的要求
隔离性:锁，mvcc（多版本并发控制）
持久性：redo log
MVCC
MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

当前读
像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

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

当前读、快照读、MVCC关系
MVCC多版本并发控制指的是维持一个数据的多个版本，使得读写操作没有冲突，快照读是MySQL为实现MVCC的一个非阻塞读功能。MVCC模块在MySQL中的具体实现是由三个隐式字段，undo日志、read view三个组件来实现的。

MVCC解决的问题
数据库并发场景有三种，分别为：

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

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

​ 3、写写：有线程安全问题，可能存在更新丢失问题

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

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

​ 2、解决脏读、幻读、不可重复读等事务隔离问题，但是不能解决更新丢失问题

MVCC实现原理
mvcc的实现原理主要依赖于记录中的隐藏字段，undolog，read view来实现的。

隐藏字段
每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段
1、DB_TRX_ID
6字节，最近修改事务id，记录创建这条记录或者最后一次修改该记录的事务id；
2、DB_ROLL_PTR
7字节，回滚指针，指向这条记录的上一个版本,用于配合undolog，指向上一个旧版本
3、DB_ROW_JD
6字节，隐藏的主键，如果数据表没有主键，那么innodb会自动生成一个6字节的row_id

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

undo log

undolog被称之为回滚日志，表示在进行insert，delete，update操作的时候产生的方便回滚的日志；

当进行insert操作的时候，产生的undolog只在事务回滚的时候需要，并且在事务提交之后可以被立刻丢弃；
当进行update和delete操作的时候，产生的undolog不仅仅在事务回滚的时候需要，在快照读的时候也需要，所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除（当数据发生更新和删除操作的时候都只是设置一下老记录的deleted_bit，并不是真正的将过时的记录删除，因为为了节省磁盘空间，innodb有专门的purge线程来清除deleted_bit为true的记录，如果某个记录的deleted_id为true，并且DB_TRX_ID相对于purge线程的read view 可见，那么这条记录一定是可以被清除的）；

undolog生成的记录链
不同事务或者相同事务的对同一记录的修改，会导致该记录的undolog生成一条记录版本线性表，即链表，undolog的链首就是最新的旧记录，链尾就是最早的旧记录。

1、假设有一个事务编号为1的事务向表中插入一条记录，那么此时行数据的状态为：

2、假设有第二个事务编号为2对该记录的name做出修改，改为lisi；

在事务2修改该行记录数据时，数据库会对该行加排他锁；
然后把该行数据拷贝到undolog中，作为 旧记录，即在undolog中有当前行的拷贝副本；
拷贝完毕后，修改该行name为lisi，并且修改隐藏字段的事务id为当前事务2的id，回滚指针指向拷贝到undolog的副本记录中；
事务提交后，释放锁；
3、假设有第三个事务编号为3对该记录的age做了修改，改为32

在事务3修改该行数据的时，数据库会对该行加排他锁；
然后把该行数据拷贝到undolog中，作为旧纪录，发现该行记录已经有undolog了，那么最新的旧数据作为链表的表头，插在该行记录的undolog最前面；
修改该行age为32岁，并且修改隐藏字段的事务id为当前事务3的id，回滚指针指向刚刚拷贝的undolog的副本记录
事务提交，释放锁；
Read View
Read View是事务进行快照读操作的时候生产的读视图，在该事务执行快照读的那一刻，会生成一个数据系统当前的快照，记录并维护系统当前活跃事务的id，事务的id值是递增的。

其实Read View的最大作用是用来做可见性判断的，也就是说当某个事务在执行快照读的时候，对该记录创建一个Read View的视图，把它当作条件去判断当前事务能够看到哪个版本的数据，有可能读取到的是最新的数据，也有可能读取的是当前行记录的undolog中某个版本的数据

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

Read View的可见性规则如下所示：

首先要知道Read View中的三个全局属性：

m_ids:一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID
min_trx_id:记录trx_list列表中事务ID最小的ID
max_trx_id:Read View生成时刻系统尚未分配的下一个事务ID
creator_trx_id:当前事务id

具体的比较规则如下：

1、如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。

2、如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。

按照ReadView中的比较规则(后两条)：

3、如果被访问版本的trx_id属性值大于或等于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
4、如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间(min_trx_id < trx_id < max_trx_id)，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

RC、RR级别下的InnoDB快照读有什么不同
因为Read View生成时机的不同，从而造成RC、RR级别下快照读的结果的不同

​ 1、在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照即Read View,将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View,所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View,所以对之后的修改不可见

​ 2、在RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动和事务的快照，这些事务的修改对于当前事务都是不可见的，而早于Read View创建的事务所做的修改均是可见

​ 3、在RC级别下，事务中，每次快照读都会新生成一个快照和Read View,这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。

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

Mysql幻读怎么解决的
事务A按照一定条件进行数据读取，期间事务B插入了相同搜索条件的新数据，事务A再次按照原先条件进行读取时，发现了事务B新插入的数据称之为幻读。

sql

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB ;

INSERT into user VALUES (1,'1',20),(5,'5',20),(15,'15',30),(20,'20',30);

执行流程如下：

1、T1时刻读取年龄为20 的数据，事务1拿到了2条记录

2、T2时刻另一个事务插入一条新的记录，年龄也是20

3、T3时刻，事务1再次读取年龄为20的数据，发现还是2条记录，事务2插入的数据并没有影响到事务1的事务读取

4、T4时刻，事务1修改年龄为20的数据，发现结果变成了三条，修改了三条数据

5、T5时刻，事务1再次读取年龄为20的数据，发现结果有三条，第三条数据就是事务2插入的数据，此时就产生了幻读情况。

一般情况下select * from …where …是快照读，不会加锁，而 for update,lock in share mode,update,delete都属于当前读。如果事务中都是用快照读，那么不会产生幻读的问题，但是快照读和当前读一起使用的时候就会产生幻读。所以在解决幻读的问题上需要加锁（for update）,这样另一个插入的事务会阻塞，不会影响当前事务的读操作，避免幻读。

sql join原理
MySQL是只支持一种Join算法Nested-Loop Join(嵌套循环连接)，并不支持哈希连接和合并连接，不过在mysql中包含了多种变种，能够帮助MySQL提高join执行的效率。

​ 1、Simple Nested-Loop Join

​ 这个算法相对来说就是很简单了，从驱动表中取出R1匹配S表所有列，然后R2，R3,直到将R表中的所有数据匹配完，然后合并数据，可以看到这种算法要对S表进行RN次访问，虽然简单，但是相对来说开销还是太大了。

​ 2、Index Nested-Loop Join

​ 索引嵌套联系由于非驱动表上有索引，所以比较的时候不再需要一条条记录进行比较，而可以通过索引来减少比较，从而加速查询。这也就是平时我们在做关联查询的时候必须要求关联字段有索引的一个主要原因。

​ 这种算法在链接查询的时候，驱动表会根据关联字段的索引进行查找，当在索引上找到了符合的值，再回表进行查询，也就是只有当匹配到索引以后才会进行回表。至于驱动表的选择，MySQL优化器一般情况下是会选择记录数少的作为驱动表，但是当SQL特别复杂的时候不排除会出现错误选择。

​ 在索引嵌套链接的方式下，如果非驱动表的关联键是主键的话，这样来说性能就会非常的高，如果不是主键的话，关联起来如果返回的行数很多的话，效率就会特别的低，因为要多次的回表操作。先关联索引，然后根据二级索引的主键ID进行回表的操作。这样来说的话性能相对就会很差。

​ 3、Block Nested-Loop Join

​ 在有索引的情况下，MySQL会尝试去使用Index Nested-Loop Join算法，在有些情况下，可能Join的列就是没有索引，那么这时MySQL的选择绝对不会是最先介绍的Simple Nested-Loop Join算法，而是会优先使用Block Nested-Loop Join的算法。

​ Block Nested-Loop Join对比Simple Nested-Loop Join多了一个中间处理的过程，也就是join buffer，使用join buffer将驱动表的查询JOIN相关列都给缓冲到了JOIN BUFFER当中，然后批量与非驱动表进行比较，这也来实现的话，可以将多次比较合并到一次，降低了非驱动表的访问频率。也就是只需要访问一次S表。这样来说的话，就不会出现多次访问非驱动表的情况了，也只有这种情况下才会访问join buffer。

​ 在MySQL当中，我们可以通过参数join_buffer_size来设置join buffer的值，然后再进行操作。默认情况下join_buffer_size=256K，在查找的时候MySQL会将所有的需要的列缓存到join buffer当中，包括select的列，而不是仅仅只缓存关联列。在一个有N个JOIN关联的SQL当中会在执行时候分配N-1个join buffer。

索引失效
1、组合索引不遵循最左匹配原则

​ 2、组合索引的前面索引列使用范围查询(<,>,like),会导致后续的索引失效

​ 3、不要在索引上做任何操作（计算，函数，类型转换）

​ 4、is null和is not null无法使用索引

​ 5、尽量少使用or操作符，否则连接时索引会失效

​ 6、字符串不添加引号会导致索引失效

​ 7、两表关联使用的条件字段中字段的长度、编码不一致会导致索引失效

​ 8、like语句中，以%开头的模糊查询

​ 9、如果mysql中使用全表扫描比使用索引快，也会导致索引失效
————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
                        
原文链接：https://blog.csdn.net/weixin_43875870/article/details/114796316