MySql MVCC 详解

已于 2023-12-06 15:31:04 修改
阅读量375 收藏 1
点赞数
分类专栏： mysql 文章标签： mysql
于 2023-12-06 15:30:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44949002/article/details/134832452
版权
本文详细介绍了InnoDB引擎的MVCC多版本并发控制机制，涉及MVCC原理、MySQL逻辑架构、事务特性与隔离级别、快照读与当前读的区别以及如何通过ReadView和可见性算法确保数据一致性，最后通过实例验证了不同隔离级别下MVCC在处理幻读问题中的表现。
摘要由CSDN通过智能技术生成

注意以下操作都是以InnoDB引擎为操作基准。

一，前置知识准备

1，MVCC简介

MVCC 是多版本并发控制（Multiversion Concurrency Control）的缩写。它是一种数据库事务管理技术，用于解决并发访问数据库的问题。MVCC 通过创建多个版本的同一数据，每个版本与一个事务关联，来实现并发控制。

数据库在执行更新操作时，会保留之前版本的数据，以便其他正在执行事务的用户可以访问这些数据。每个事务都能看到一个稳定的数据快照，并且仅接触到他们自己的版本，这意味着每个事务可以独立地读取和写入数据，而不会干扰其它事务。

MVCC 在数据库的可伸缩性和性能方面具有重要作用，尤其是对于高并发的应用程序，如电子商务网站和社交媒体应用。

2，MySQL的逻辑架构

第一层：处理客户端连接、授权认证，安全校验等。

第二层：服务器server层，负责对SQL解释、分析、优化、执行操作引擎等。

第三层：存储引擎，负责MySQL中数据的存储和提取。
在这里插入图片描述

3，事务的四大特性

ACID是指数据库事务所必须具备的四个特性，包括：

  1. 原子性（Atomicity）：事务是一个不可分割的原子操作，要么全部执行成功，要么全部失败回滚，不允许出现部分执行成功或失败的情况。【undolog】

  2. 一致性（Consistency）：事务执行前和执行后，数据库的完整性约束没有被破坏，也就是说，在事务完成后，数据库从一个一致性状态转变为另一个一致性状态。

  3. 隔离性（Isolation）：事务之间是相互隔离的，一个事务的执行不能被其他事务干扰。多个事务并发执行时，它们之间的执行是独立的，每个事务感觉就像是在独占数据库。【锁，mvcc】

  4. 持久性（Durability）：事务完成后，对于数据的修改是永久性的，即使系统故障也不会导致数据的丢失。因此，数据库中所有的数据修改都需要记录到日志中，以便在系统故障恢复时进行重做。【redolog】

4，事务的四大隔离级别

事务的隔离级别是指多个事务同时操作一个数据库时，数据库系统对这些事务分配的隔离程度。在不同的隔离级别下，事务之间的隔离程度也不同。常见的隔离级别包括：

  1. 读未提交（Read Uncommitted）：允许一个事务读取另一个事务未提交的数据。这种隔离级别对数据的完整性和一致性影响较大。【存在脏读】

  2. 读已提交（Read Committed）：一个事务只能读取已经提交的数据，其他未提交的事务所做的修改对它不可见。这种隔离级别对数据完整性和一致性的保护较好。【解决脏读，存在不可重复读】【mysql InnoDB 通过 mvcc 解决 】

  3. 可重复读（Repeatable Read）：一个事务在执行期间看到的数据是固定的，不受其他并发事务的影响。即使其他事务已经提交了对数据的修改，当前事务也只能看到自己在读取数据时的版本。这种隔离级别对数据的完整性和一致性有一定保护。【解决不可重复读，存在幻读】【mysql InnoDB 通过 mvcc 解决 】

  4. 串行化（Serializable）：最高的隔离级别，确保事务之间的操作是完全独立的，一个事务的操作必须等另一个事务结束后才能开始。这种隔离级别对数据完整性和一致性的保护最好，但并发性能较低。【解决脏读，解决不可重复读，解决幻读】【mysql InnoDB 通过 加锁解决 】

在实际应用中，应根据业务需求和系统性能等因素选择合适的隔离级别。

5，mysql 常用的日志

server 层

  1. 错误日志(Error Log): 记录 MySQL 服务器启动、运行过程中出现的重要错误和警告信息。
  2. 慢查询日志(Slow Query Log): 记录执行时间超过预设时间的查询语句，通常用于优化查询性能。
  3. 二进制日志(Binary Log): 记录数据库更新操作，用于主从复制和数据恢复。
  4. 中继日志(Relay Log): 只在主从复制时使用，记录从服务器复制主服务器二进制日志的过程。

引擎层

  • 重做日志(Redo log): 是一种用于恢复数据库中未提交和已提交事务的机制。其包含了所有已经被写入到磁盘上的事务，通常被存储在磁盘上的一组文件中。当数据库系统宕机或者发生崩溃时，可以通过redo log来恢复数据库并且保证ACID属性。
  • 回滚日志(Undo log): 则用于撤销已经提交或者未提交的事务。它记录了事务执行前的数据，以便当出现错误时可以将数据回滚到事务执行前的状态。在数据库中，undo log通常被用于避免脏读、不可重复读和幻读等问题。

二，mvcc 原理

1，当前读和快照读

在学习 MVCC 多版本并发控制之前，我们必须先了解一下，什么是 MySQL InnoDB 下的当前读和快照读。

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

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

在InnoDB中的每一条记录实际都会存在三个隐藏列

  • DB_TRX_ID：事务 ID，是根据事务产生时间顺序自动递增的，是独一无二的。如果某个事务执行过程中对该记录执行了增、删、改操作，那么InnoDB存储引擎就会记录下该条事务的 id。

  • DB_ROLL_PTR：回滚指针，本质上就是一个指向记录对应的undo log的一个指针，InnoDB 通过这个指针找到之前版本的数据

  • DB_ROW_ID：主键，如果有自定义主键，那么该值就是主键；如果没有主键，那么就会使用定义的第一个唯一索引；如果没有唯一索引，那么就会默认生成一个隐藏列作为主键。
    在这里插入图片描述

2，undolog

这些数据快照都是存储在undolog 中的，这些数据分为两类

  • Insert undo log ：insert生成的日志，仅在事务回滚中需要，并且可以在事务提交后立即丢弃。

  • Update undo log：update/delete生成的日志，除了用于事务回滚，还用于一致性读取，只有不存在innodb为其分配快照的事务之后才能丢弃它们，在一致读取中可能需要update undo log中的信息来构建数据库行的早期版本。

删除操作实际上不会直接删除，而只是标记为删除，最终的删除操作是purge线程完成的

purge线程作用，一是清理undo log，二是清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识删除，真正的删除工作需要后台purge线程去完成。

3，Read View(读视图)

事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照。

记录并维护系统当前活跃事务的ID(trx_id)(没有commit，当每个事务开启时，都会被分配一个ID,
这个ID是递增的，所以越新的事务，ID值越大)，是系统中当前不应该被本事务看到的其他事务id列表。

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

Read View几个属性
在这里插入图片描述

MVCC 只在 Read Commited（读已提交） 和 Repeatable Read（可重读读） 两种隔离级别下工作。

  • 在RC隔离级别下，是每个快照读都会生成并获取最新的Read View，这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。

  • 在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View，从而做到可重复读。

4，可见性算法

1、首先比较DB_TRX_ID < up_limit_id,如果小于，则当前事务能看到DB_TRX_ID所在的记录，如果大于等于进入下一个判断。

2、接下来判断DB_TRX_ID >= low_limit_id,如果大于等于则代表DB_TRX_ID所在的记录在Read View生成后才出现的，那么对于当前事务肯定不可见，如果小于，则进入下一步判断。

3、判断DB_TRX_ID是否在活跃事务中，如果在，则代表在Read View生成时刻，这个事务还是活跃状态，还没有commit，修改的数据，当前事务也是看不到，如果不在，则说明这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的。

5，mvcc能否解决幻读
在一次事务里面，多次查询之后，结果集的个数不一致的情况叫做幻读。而多出来或者少的哪一行被叫做幻行。

在快照读读情况下，mysql通过mvcc来避免幻读。

在当前读读情况下，mysql通过next-key来避免幻读。

不能把快照读和当前读得到的结果不一样这种情况认为是幻读，这是两种不同的使用。所以mysql的RR级别是解决了幻读的。

三，mvcc 场景验证

所谓光说不练假把式，光练不说傻把式，又练又说真把式，上面说的只是结论，下面进行实际的操作演示。

mysql 版本 5.7

创建测试表

CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) DEFAULT NULL,
  `age` tinyint(3) DEFAULT NULL,
  `gender` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_abc` (`name`,`age`,`gender`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8

（开始之前将事务自动提交关闭）

1，场景一

当前的事务隔离级别为，可重复读（Repeatable Read）
在这里插入图片描述

步骤一，t1时刻同时开启事务

步骤二，t2时刻事务2更新并提交

步骤三，t3时刻事务1查询

问题，事务1在t3时刻是否能查询t2时刻事务2提交的数据。

预期结果能

因为执行的是select所以为快照读，但是由于Read View是在快照读的时候才产生，并且可重复读（Repeatable
Read）隔离级别下，只产生一个Read
View。事务2更新并提交完成时候，由于此时事务1还没进行快照读。所以此时事务1查询的时候是可以查询到事务2更新并提交后的数据的。

sql 执行验证
在这里插入图片描述

查询结果符合预期

通过算法核对

trx_list：1，3 【当前活跃事务为 1，3，因为2已经提交了】

low_limit_id：4【当前系统最大事务版本号+1，因为已经开启了3个事务，所以下一个应该是4】

up_limit_id：1 【创建当前read view 时“系统正处于活跃事务最小版本号，活跃的只有1，3，最小的是1】
在这里插入图片描述

算法验证：验证当前事务1是否能看到事务2提交的数据。

（1）DB_TRX_ID < up_limit_id 【2<1】不成立继续判断

（2）DB_TRX_ID >= low_limit_id 【2>=4】不成立继续判断

（3）判断DB_TRX_ID是否在活跃事务中，不在，则说明这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的。

2，场景二

当前的事务隔离级别为，可重复读（Repeatable Read）
在这里插入图片描述

步骤一，t1时刻同时开启事务

步骤二，t2时刻事务1进行快照读

步骤三，t3时刻事务2修改并提交

步骤四，t4时刻事务1进行快照读

问题，事务1在t4时刻是否能查询t3时刻事务2提交的数据。

预期结果不能

事务1在t2时刻执行的是select所以为快照读，此时Read View产生，并且可重复读（Repeatable
Read）隔离级别下，只产生一个Read View。事务2在t3更新并提交完成时候，由于此时事务1已经产生了Read
View，再次进行快照读。所以此时事务1查询的时候是可以查询不到事务2更新并提交后的数据的，因为读取的是快照中的数据。

在这里插入图片描述

sql 执行验证

查询结果符合预期

通过算法核对

第一次查询

trx_ids：1,2,3 【当前活跃事务为 1，2，3，此时事务2还没开始修改提交】

low_limit_id：4【当前系统最大事务版本号+1，因为已经开启了3个事务，所以下一个应该是4】

up_limit_id：1 【创建当前read view 时“系统正处于活跃事务最小版本号，活跃的只有1，3，最小的是1】

第二次查询

可重复读（Repeatable Read）事务隔离级别下只产生一个read view

trx_ids：1,3 【当前活跃事务为 1，3，此时事务2已经修改提交】

low_limit_id：4【当前系统最大事务版本号+1，因为已经开启了3个事务，所以下一个应该是4】

up_limit_id：1 【创建当前read view 时“系统正处于活跃事务最小版本号，活跃的只有1，3，最小的是1】

在这里插入图片描述

第二次快照读的时候，当前数据的DB_TRX_ID为2

（1）DB_TRX_ID < up_limit_id 【2<1】不成立继续判断

（2）DB_TRX_ID >= low_limit_id 【2>=4】不成立继续判断

（3）判断DB_TRX_ID是否在活跃事务中，在，则代表在Read View生成时刻，这个事务还是活跃状态，还没有commit，修改的数据，当前事务也是看不到。

3，场景三

当前的事务隔离级别为，可重复读（Repeatable Read）

如果事务中全部都是快照读，不会产生幻读问题，但是当快照读和当前读一起使用的时候就会产生幻读问题。

Mysql的解决方案是加锁，想要解决这个问题，必须要保证当前读和快照读的数据必须要一致，只能去阻止其他事务进行插入操作，所以只能加锁。

sql 执行验证

1，如果事务中全部都是快照读，不会产生幻读问题

在这里插入图片描述

2，当快照读和当前读一起使用的时候就会产生幻读问题
在这里插入图片描述

3，如果事务中全部都是当前读，不会产生幻读问题【加锁实现的】

在这里插入图片描述

提交后立刻执行
在这里插入图片描述

4，场景四

当前的事务隔离级别为，读已提交（Read Committed）

验证在此隔离级别，每一次快照读都会产生一次新的read view
在这里插入图片描述

步骤一，t1时刻同时开启事务

步骤二，t2时刻事务1进行快照读

步骤三，t3时刻事务2修改并提交

步骤四，t4时刻事务1进行快照读

问题，事务1在t4时刻是否能查询t3时刻事务2提交的数据。

预期结果能

事务1在t2时刻执行的是select所以为快照读，此时Read View产生，读已提交（Read
Committed）隔离级别下，产生多个Read
View。所以事务2在t3更新并提交完成时候，事务1在t4时刻再次进行快照读。此时又产生了新的Read View。新的Read
View是在t3时刻事务2修改并提交产生的所以可以查看到。

sql 验证
在这里插入图片描述

符合预期结果

通过算法核对

第一次查询

trx_ids：1,2,3 【当前活跃事务为 1，2，3，此时事务2还没开始修改提交】

low_limit_id：4【当前系统最大事务版本号+1，因为已经开启了3个事务，所以下一个应该是4】

up_limit_id：1 【创建当前read view 时“系统正处于活跃事务最小版本号，活跃的只有1，3，最小的是1】

第二次查询

可重复读（Repeatable Read）事务隔离级别下只产生一个read view

trx_ids：1,3 【当前活跃事务为 1，3，此时事务2已经修改提交】

low_limit_id：4【当前系统最大事务版本号+1，因为已经开启了3个事务，所以下一个应该是4】

up_limit_id：1 【创建当前read view 时“系统正处于活跃事务最小版本号，活跃的只有1，3，最小的是1】

在这里插入图片描述

第二次快照读的时候，当前数据的DB_TRX_ID为2

（1）DB_TRX_ID < up_limit_id 【2<1】不成立继续判断

（2）DB_TRX_ID >= low_limit_id 【2>=4】不成立继续判断

（3）判断DB_TRX_ID是否在活跃事务中，不在，则说明这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的。

qq_44949002
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
mysql中的mvcc
qq_37517776的博客
03-13 2468
什么是MVCC 多版本并发控制,读取数据时通过一种类似快照方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事物session会看到自己特定版本的数据——版本链 MVCC只在READ COMMITED和REPEATABLE READ 两个隔离级别下工作，应为READ UNCOMMITED总是读取最新的数据行，而不是符合当前事务的数据行。儿SERIALIZABLE则会对读取所有的行都加锁。 在聚簇索引记录中有两个必要的隐藏列： **trx_id:**用来存储每次对某条聚簇索引记录进行修改的事物Id。 **r
Mysql中的MVCC
热门推荐
老码农的专栏
09-04 8万+
Mysql到底是怎么实现MVCC的？这个问题无数人都在问，但google中并无答案，本文尝试从Mysql源码中寻找答案。   在Mysql中MVCC是在Innodb存储引擎中得到支持的，Innodb为每行记录都实现了三个隐藏字段： 6字节的事务ID（DB_TRX_ID
mysql的mvcc详解
健康平安的活着的专栏
09-28 4259
1。即通过数据行的多个版本管理来实现数据库的并发控制，使得在InnoDB事务隔离级别下执行一致性读操作有了保障。2.mysql中的InnoDB中实现了，大大提高数据库的并发度。3..MySQl中只有InnoDB支持MVCC，其他存储引擎不支持4.为了查询一些正在被其他事务更新的值的时候，能够查到它们被更新之前的值，这样做就能在查询的时候不必等待更新事务的提交。
mysql中的MVCC
Sunmeok的博客
10-14 511
学任何东西都是循序渐进的过程 之前看了这方面的东西，那时候很心急，因此很多东西不能完全理解。今天再次拿出来看 首先学习MVCC我们先要去学习redo log 和undo log这些日志是干嘛的 undo log： 存储了数据先前的版本 我们的mysql事务有一特性称为原子性，undo log就完成了这一特性。它是这样实现的：首先我们将数据读取到内存中，然后在内存中修改数据，在修改任何数据...
多版本并发控制
weixin_48777366的博客
06-04 351
MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的。这项技术使得在InnoDB的事务隔离级别下执行操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的(大家可以参考相关的DBMS文档)。这里讲解InnoDB 中MVCC的实现机
Mysql知识详解（内容非常丰富）
最新发布
12-19
- 锁机制：MYISAM使用表级锁，InnoDB使用行级锁，支持MVCC（多版本并发控制）。 - 外键：MYISAM不支持，InnoDB支持。 - 主键：MYISAM允许没有索引或主键，InnoDB要求有主键或非空唯一索引。 - 全文索引：MYISAM支持...
MySQL备份原理详解
12-15
在备份InnoDB表时，会利用MVCC确保数据一致性。尽管Mysqldump效率较高，但在大规模数据库中，备份速度可能较慢。 为了解决这个问题，社区开发了Mydumper工具，它采用多线程备份，显著提升了备份速度。Mydumper同样...
Mysql面试题详解（个人整理）
10-08
- **MVCC（多版本并发控制）**：InnoDB支持MVCC，提高了并发读写的能力，而MYISAM不支持。 - **全文索引**：MYISAM支持全文索引，适合全文搜索需求，而InnoDB不支持。 - **可移植性和备份恢复**：MYISAM数据文件...
一线大厂Mysql面试题详解.pdf
02-07
MySQL面试题详解 本文档将详细解释MySQL面试中的一些常见问题，包括MySQL的复制原理、InnoDB与MyISAM的区别、varchar与char的区别、事务与日志的实现方式等。 MySQL的复制原理 ---------------- MySQL的复制原理...
MySQL数据库事务隔离级别详解
12-16
不过，MySQL的InnoDB存储引擎在“Repeatable Read”级别下通过MVCC（多版本并发控制）和间隙锁策略，可以避免幻读。而在MyISAM引擎下，幻读则可能出现。 4. 串行化（Serializable）： 这是最高的隔离级别，完全避免...
正确理解MySQL的MVCC及实现原理
qq_43568704的博客
09-15 2886
MVCC多版本并发控制 目录 MVCC多版本并发控制 前提概要 什么是MVCC? 什么是当前读和快照读？ 当前读，快照读和MVCC的关系 MVCC的实现原理 隐式字段 undo日志 Read View(读视图) 整体流程 MVCC相关问题 RR是如何在RC级的基础上解决不可重复读的？ RC,RR级别下的InnoDB快照读有什么不同？ 转载于：https://blog.csdn.net/SnailMann/article/details/94724197?utm_medium=d
MySQL的MVCC是什么
学习是一种信仰的博客
03-05 1854
MVCC是什么
MySQL之MVCC
Redemption
04-05 1164
MVCC（多版本并发控制） MVCC叫做多版本并发控制，读取数据时通过一种类似快照的方式将数据保存下来，不同的事务会看到自己特定版本的数据，这样读锁和写锁就不冲突了，提高了数据库的读写效率。 MVCC主要是处理读请求的，这个读主要处理的是快照读，而不是当前读。 快照读（一致性非锁定读），是基于MVCC的，读到的数据不一定是当前最新的数据，有可能是之前历史版本的数据。 当前读（锁定读），其实是一种悲观锁，需要去加锁。读取的是最新版本的数据，比如我们执行insert、update或delete的时候，
mysql mvcc介绍
小城我家
09-09 312
MVCC 多版本控制MVCC，也就是Copy on Write的思想。MVCC除了支持读和读并行，还支持读和写、写和读的并行，但为了保证一致性，写和写是无法并行的。 在事务1开始写操作的时候会copy一个记录的副本，其他事务读操作会读取这个记录副本，因此不会影 响其他事务对此记录的读取，实现写和读并行。 一、MVCC概念 MVCC（Multi Version Concurrency Control）被称为多版本控制，是指在数据库中为了实现高并发的数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务
MySQL的MVCC
学而不思则忘
03-20 172
1. MVCC简介 MVCC （multiversion concurrency control），多版本并发控制，主要是通过在每一行记录中增加三个字段，与 undo log 中相关记录配合使用，同时加上可见性算法，使得各个事务可以在不加锁的情况下能够同时地读取到某行记录上的准确值（这个值对不同的事务而言可能是不同的）。使用 MVCC，在不加锁的情况下也能读取到准确的数据，大大提高了并发效率。 2. 更新操作 在数据库表的记录中，每一个记录都会添加三个字段： DBTRXID：6个字节，表示最近一次修改本记
mysql的MVCC
奔跑的菜鸡
10-06 198
概念 MVCC，全称 Multi-Version Concurrency Control ，即多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。 当前读和快照读 当前读 像 select lock in share mode (共享锁), select for update; update; insert; delete (排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修
MYSQL中的MVCC
zhoxing
08-27 988
什么是MVCC MVCC即Multi-Version Concurrency Control，中文翻译过来叫多版本并发控制。 MVCC是解决了什么问题 众所周知，在MYSQL中，MyISAM使用的是表锁，InnoDB使用的是行锁。而InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ需要两个不同的事务相互之间不能影响，而且还能支持并发，这点悲观锁是
mysql mvcc机制详解
09-17
### 回答1： MySQL的MVCC（Multi-Version Concurrency Control）机制是通过为每个读操作创建一个版本（Version）并保留旧版本来实现的。这个机制允许多个事务同时访问同一数据行，同时确保它们不会互相干扰或产生冲突。 MVCC在MySQL中的实现方式是，对于每一行数据，在表中存储一个隐藏的系统版本号（system versioning），并将每个操作（包括SELECT查询）的时间戳与该行的版本号进行比较。当读取一行数据时，MySQL会根据当前的事务时间戳和行的版本号来决定该行是否可见。如果行的版本号早于当前事务的时间戳，则说明该行是旧版本，不可见；如果行的版本号晚于当前事务的时间戳，则说明该行是新版本，可见。 在MVCC机制下，读操作不会阻塞写操作，写操作也不会阻塞读操作。因此，MVCC机制可以提高并发性能和可伸缩性，使得多个事务可以同时访问同一数据库而不会产生锁定和阻塞问题。 但是，MVCC机制也有一些限制。例如，如果事务A在读取某个数据行的同时，事务B修改了该行的值，那么事务A在提交时就会检测到该数据行已经被修改，从而回滚该操作。此外，MVCC机制也会占用更多的存储空间来存储旧版本的数据行。 ### 回答2： MySQL的MVCC（多版本并发控制）是一种用于处理并发访问的机制。MVCC是通过在数据库的各种操作（如事务的开启、读取和写入）中使用隐藏的时间戳来实现的。 MVCC的主要目标是避免读取和写入操作之间的冲突，从而提高数据库的并发性能和资源利用率。它通过在内部为每个事务提供一个唯一的时间戳来实现。每个事务在开始时都会获得一个时间戳，并且事务中的每个操作都使用这个时间戳。 当一个事务读取数据时，它只能读取它开始时间之前的数据版本。这样可以避免读取到其他事务正在写入或修改的数据，从而保证读取操作的一致性和隔离性。 当一个事务写入数据时，它会创建一个新的数据版本，并将其与事务的时间戳关联。这个新版本的数据不会立即覆盖旧的数据，而是以一种类似于快照的方式存在。其他事务在读取数据时仍然可以访问旧版本的数据。 MVCC还使用了回滚段（undo log）来处理事务的回滚操作。当一个事务被回滚时，数据库会使用回滚段将所有该事务做出的修改逆转回去，从而恢复到事务开始之前的状态。 需要注意的是，MVCC机制对于并发性能和资源利用率的提升是有限的。在高并发的情况下，数据库可能会出现锁等待和资源竞争的问题。为了进一步优化并发性能，可以考虑使用其他技术，如乐观并发控制（Optimistic Concurrency Control）和分布式数据库。 ### 回答3： MySQL的MVCC（Multi-Version Concurrency Control）机制是一种并发控制技术，用于处理数据库中的读写冲突。它允许多个事务同时读取数据库，同时也使得读写冲突被有效地解决。 MVCC机制基于以下两个重要的概念：版本号和快照。 首先，每个表中的每个行都有一个版本号。当一个事务对某行进行修改时，会为该事务创建一个新的版本，并将旧版本标记为过期。这样，读取该行的事务会读取到未过期的版本，而不会受到写用户的影响。同时，这也避免了仅读用户被阻塞的情况。 其次，为了实现读取未过期版本的行，MVCC机制通过创建快照来实现。快照是数据库在某个时间点的一个镜像，其中包含了未过期的行版本。当一个读取事务开始时，会生成一个当前的数据库快照，并基于这个快照来读取数据行。这样，读取事务不会看到在其开始时（即快照生成时）已提交的写入事务，从而实现了读写并发。 MVCC机制对于提高数据库的并发性能非常重要。它允许多个事务同时进行读操作，提高了数据库的并发处理能力。此外，它也避免了读写冲突和阻塞的情况，提高了数据库的效率和稳定性。 总之，MySQL的MVCC机制通过使用版本号和快照来实现读写并发控制和冲突的解决。它是提高数据库并发性能和减少阻塞的关键技术之一，并且在实际的数据库应用中扮演着非常重要的角色。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值