多版本并发控制MVCC

最新推荐文章于 2024-06-16 05:34:45 发布
最新推荐文章于 2024-06-16 05:34:45 发布
阅读量332 收藏
点赞数 1
分类专栏： MySql 文章标签： mysql 数据库 MVCC
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_61427900/article/details/133977389
版权

什么是MVCC

MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。

快照读与当前读

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读，而这个读指的就是快照读, 而非当前读。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

快照读

快照读又叫一致性读，读取的是快照数据。 不加锁的简单的 SELECT 都属于快照读 ，即不加锁的非阻塞读；比如这样：

select * from table where ...

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。
既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。

当前读

当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。比如：

select * from student lock in share mode; # 共享锁，S锁

select * from student for update; # 排他锁，X锁

insert into student values ... # X锁

delete from student where ... # X锁

update student set ... # X锁

前置知识

隔离级别

我们知道事务有4个隔离级别，存在3种并发问题。
image.png
在MySQL中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，如果仅从定义的角度来看，它并不能解决幻读问题。如果我们想要解决幻读问题，就需要采用串行化的方式，也就是将隔离级别提升到最高，但这样一来就会大幅降低数据库的事务并发能力。
而MVCC 可以不采用锁机制，而是通过乐观锁的方式来解决不可重复读和幻读问题!它可以在大多数情况下替代行级锁，降低系统的开销。
image.png

隐藏字段，undo log版本链

回顾一下undo日志的版本链，对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列(字段)。

  • trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。
  • roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

举例：student表的数据如下

mysql> select *from student;
+----+--------+--------+
| id | name   | class  |
+----+--------+--------+
|  1 | 张三   | 一班   |
+----+--------+--------+
1 row in set (0.01 sec)

假设插入该记录的事务id为8，那么此刻该条记录的示意图如下所示:
image.png

insert undo只在事务回滚时起作用，当事务提交后，该类型的undo日志就没用了，它占用的UndoLog Segment也会被系统回收（也就是该undo日志占用的Undo页面链表要么被重用，要么被释放）。

假设之后两个事务id分别为 10 、 20 的事务对这条记录进行UPDATE操作，操作流程如下：
image.png

能不能在两个事务中交叉更新同一条记录呢?不能!这不就是一个事务修改了另一个未提交事务修改过的数据，脏写。
InnoDB使用锁来保证不会有脏写情况的发生，也就是在第一个事务更新了某条记录后，就会给这条记录加锁，另一个事务再次更新时就需要等待第一个事务提交了，把锁释放之后才可以继续更新

每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表：
image.png
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。
每个版本中还包含生成该版本时对应的事务id。

MVCC实现原理之ReadView

:::success
MVCC 的实现依赖于： 隐藏字段、Undo Log、Read View 。
:::

什么是ReadView

在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在Undo Log里。如果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢?这时就需要用到ReadView了，它帮我们解决了行的可见性问题。
ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID(“活跃"指的就是，启动了但还没提交)。

设计思路

使用READ UNCOMMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以读到的是最新版本的记录。
使用SERIALIZABLE隔离级别的事务，InnoDB规定使用加锁的方式来访问记录，因此读取到的记录也是最新版本。
使用READ COMMITTED和REPEATABLE READ隔离级别的事务，都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。
ReadView中主要包含 4 个比较重要的内容，分别如下：

  1. creator_trx_id，创建这个 Read View 的事务 ID。

说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为 0 。

  1. trx_ids，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表
  2. up_limit_id，活跃的事务中最小的事务 ID。
  3. low_limit_id，表示生成ReadView时系统中应该分配给下一个事务的id值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。

注意：low_limit_id并不是trx_ids中的最大值，事务id是递增分配的。比如，现在有id为 1 ，2 ， 3 这三个事务，之后id为 3 的事务提交了。那么一个新的读事务在生成ReadView时，trx_ids就包括 1 和 2 ，up_limit_id的值就是 1 ，low_limit_id的值就是 4 。

**举例：
**trx_ids为tr2、tr3、tr:5和trx8的集合，系统的最大事务ID (low_limit_id)为trx8+1(如果之前没有其他的新增事务)，活跃的最小事务ID (up_limit_id)为trx2。
image.png

ReadView的规则

有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。

  • 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值小于ReadView中的up_limit_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值大于或等于ReadView中的low_limit_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
  • 如果被访问版本的trx_id属性值在ReadView的up_limit_id和low_limit_id之间，那就需要判断一下trx_id属性值是不是在trx_ids列表中。
    • 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

MVCC整体操作流程

了解了这些概念之后，我们来看下当查询一条记录的时候，系统如何通过MVCC找到它：

  1. 首先获取事务自己的版本号，也就是事务 ID；
  2. 生成 ReadView；
  3. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
  4. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
  5. 最后返回符合规则的数据。

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

lnnoDB中，MVCC是通过Undo Log + Read View进行数据读取，Undo Log保存了历史快照，而Read View规则帮我们判断当前版本的数据是否可见。

在隔离级别为读已提交（Read Committed）时，一个事务中的每一次 SELECT 查询都会重新获取一次Read View。
如表所示：
image.png

注意，此时同样的查询语句都会重新获取一次 Read View，这时如果 Read View 不同，就可能产生不可重复读或者幻读的情况。

当隔离级别为可重复读的时候，就避免了不可重复读，这是因为一个事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View，如下表所示：
image.png

举例说明整个流程

假设现在student表中只有一条由事务id为8的事务插入的一条记录:

mysql> select *from student;
+----+--------+--------+
| id | name   | class  |
+----+--------+--------+
|  1 | 张三   | 一班   |
+----+--------+--------+
1 row in set (0.01 sec)

MVCC只能在READ COMMITTED和REPEATABLE READ两个隔离级别下工作。接下来看一下READ COMMITTED和REPEATABLE READ所谓的生成ReadView的时机不同到底不同在哪里。

Read Commited隔离级别下

READ COMMITTED ：每次读取数据前都生成一个ReadView 。
现在有两个事务id分别为 10 、 20 的事务在执行：

# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id= 1 ;
UPDATE student SET name="王五" WHERE id= 1 ;

# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...

说明:事务执行过程中，只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语句)，才会被 分配一个单独的事务id，这个事务id是递增的。所以我们才在事务20中更新些别的表的记录，目的是让它分配事务id。

此刻，表student中id为1的记录得到的版本链表如下所示：
image.png
假设现在有一个使用READ COMMITTED隔离级别的事务开始执行：

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、 20 未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值为'张三'

这个SELECT1的执行过程如下:
步骤1: 在执行SELECT语句时会先生成一个ReadView , ReadView的 trx_ids列表的内容就是[10，20]，up_limit_id为10, low_limit_id为21, creator_trx_id为0。
步骤2:从版本链中挑选可见的记录，从图中看出，最新版本的列name的内容是’王五’，该版本的trx_id值为10，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3:下一个版本的列name的内容是’李四’，该版本的trx_id值也为10，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4:下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为‘张三’的记录。
之后，我们把事务id为 10 的事务提交一下：

# Transaction 10
BEGIN;

UPDATE student SET name="李四" WHERE id= 1 ;
UPDATE student SET name="王五" WHERE id= 1 ;

COMMIT;

然后再到事务id为 20 的事务中更新一下表student中id为 1 的记录：

# Transaction 20
BEGIN;

# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id= 1 ;
UPDATE student SET name="宋八" WHERE id= 1 ;

此刻，表student中id为 1 的记录的版本链就长这样：
image.png
然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个id为 1 的记录，如下：

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、 20 均未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值为'张三'

# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值为'王五'

这个SELECT2的执行过程如下:
步骤1:在执行SELECT语句时会又会单独生成一个ReadView，该ReadView的trx_ids列表的内容就是[20],up_limit_id为.20,low_limit_id为21, creator_trx_id为0。
步骤2:从版本链中挑选可见的记录，从图中看出，最新版本的列name的内容是‘宋八‘，该版本的trx_id值为20，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3:下一个版本的列name的内容是‘钱七’，该版本的trx_id值为20，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4:下一个版本的列name的内容是’王五’，该版本的trx_id值为10，小于ReadView中的up_limit_id值20，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为‘王五‘的记录。

强调: 使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。

Repeatable Read隔离级别下

Repeatable Read：只会生成一个ReadView
比如，系统里有两个事务id分别为 10 、 20 的事务在执行：

# 开始记录
mysql> select *from student;
+----+--------+--------+
| id | name   | class  |
+----+--------+--------+
|  1 | 张三   | 一班   |
+----+--------+--------+
1 row in set (0.01 sec)

# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id= 1 ;
UPDATE student SET name="王五" WHERE id= 1 ;

# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...

此刻，表student 中id为 1 的记录得到的版本链表如下所示：
image.png
假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：

# 使用REPEATABLE READ隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、 20 未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值为'张三'

这个SELECT1的执行过程如下（第一个ReadView和读已提交是一样的):
步骤1: 在执行SELECT语句时会先生成一个ReadView , ReadView的 trx_ids列表的内容就是[10，20]，up_limit_id为10, low_limit_id为21, creator_trx_id为0。
步骤2:从版本链中挑选可见的记录，从图中看出，最新版本的列name的内容是’王五’，该版本的trx_id值为10，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3:下一个版本的列name的内容是’李四’，该版本的trx_id值也为10，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4:下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为‘张三’的记录。
之后，我们把事务id为 10 的事务提交一下：

# Transaction 10
BEGIN;

UPDATE student SET name="李四" WHERE id= 1 ;
UPDATE student SET name="王五" WHERE id= 1 ;

COMMIT;

然后再到事务id为 20 的事务中更新一下表student中id为 1 的记录：

# Transaction 20
BEGIN;

# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id= 1 ;
UPDATE student SET name="宋八" WHERE id= 1 ;

此刻，表student 中id为 1 的记录的版本链长这样：
image.png
然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个id为 1 的记录，如下：

# 使用REPEATABLE READ隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、 20 均未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值为'张三'

# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1 ; # 得到的列name的值仍为'张三'

这个SELECT2的执行过程如下:
步骤1:在执行SELECT语句时会继续使用之前的ReadView，该ReadView的trx_ids列表的内容就是[10，20]，up_limit_id为10, low_limit_id为21, creator_trx_id为0。
步骤2:然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是’宋八’，该版本的trx_id值为20，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3:下一个版本的列name的内容是’钱七’，该版本的trx_id值为20，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4∶下一个版本的列name的内容是’王五’，该版本的trx_id值为10，而trx_ids列表中是包含值为10的事务id的，所以该版本也不符合要求，同理下一个列name的内容是’李四’的版本也不符合要求。继续跳到下一个版本。
步骤5∶下一个版本的列name的内容是‘张三’，该版本的trx_id值为80，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列c为‘张三’的记录。
两次SELECT查询得到的结果是重复的，记录的列c值都是‘张三’，这就是可重复读的含义。如果我们之后再把事务id为20的记录提交了，然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个id为1的记录，得到的结果还是‘张三’，具体执行过程大家可以自己分析一下。

解决幻读问题

假设现在表 student 中只有一条数据，数据内容中，主键 id=1，隐藏的 trx_id=10，它的 undo log 如下图所示。
image.png
假设现在有事务 A 和事务 B 并发执行，事务 A 的事务 id 为 20 ，事务 B 的事务 id 为 30 。
步骤 1 ：事务 A 开始第一次查询数据，查询的 SQL 语句如下。

select * from student where id >= 1 ;

在开始查询之前，MySQL 会为事务 A 产生一个 ReadView，此时 ReadView 的内容如下：trx_ids=[20,30]，up_limit_id=20，low_limit_id=31，creator_trx_id=20。
由于此时表 student 中只有一条数据，且符合 where id>=1 条件，因此会查询出来。然后根据 ReadView 机制，发现该行数据的trx_id=10，小于事务 A 的 ReadView 里 up_limit_id，这表示这条数据是事务 A 开 启之前，其他事务就已经提交了的数据，因此事务 A 可以读取到。
结论：事务 A 的第一次查询，能读取到一条数据，id=1。
步骤 2 ：接着事务 B(trx_id=30)，往表 student 中新插入两条数据，并提交事务。

insert into student(id,name) values( 2 ,'李四');
insert into student(id,name) values( 3 ,'王五');

此时表student 中就有三条数据了，对应的 undo 如下图所示：
image.png
步骤 3 ：接着事务 A 开启第二次查询，根据可重复读隔离级别的规则，此时事务 A 并不会再重新生成ReadView。此时表 student 中的 3 条数据都满足 where id>=1 的条件，因此会先查出来。然后根据ReadView 机制，判断每条数据是不是都可以被事务 A 查到。
1 ）首先 id=1 的这条数据，前面已经说过了，可以被事务 A 看到。
2 ）然后是 id=2 的数据，它的 trx_id=30，此时事务 A 发现，这个值处于 up_limit_id 和 low_limit_id 之 间，因此还需要再判断 30 是否处于 trx_ids 数组内。由于事务 A 的 trx_ids=[20,30]，因此在数组内，意味着id=2 的这条数据是与事务 A 在同一时刻启动的其他事务提交的，所以这条数据不能让事务 A 看到。
3 ）同理，id=3 的这条数据，trx_id 也为 30 ，因此也不能被事务 A 看见。
image.png
结论：最终事务 A 的第二次查询，只能查询出 id=1 的这条数据。这和事务 A 的第一次查询的结果是一样的，因此没有出现幻读现象，所以说在 MySQL 的可重复读隔离级别下，不存在幻读问题。

指挥部在下面
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
mysql多版本并发控制MVCC的实现
09-09
主要介绍了mysql多版本并发控制MVCC的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
MYSQL数据库多版本并发控制（MVCC）
08-17
MYSQL数据库多版本并发控制（MVCC） MYSQL数据库的多版本并发控制（MVCC）是一种提高并发的技术。MVCC的出现使得MySQL数据库的并发度大幅度提高。MVCC的实现依赖于隐藏字段、undo log日志、read view等机制。 1. ...
多版本并发控制 MVCC
飞鱼的博客
09-14 274
介绍多版本并发控制 多版本并发控制技术（Multiversion Concurrency Control，MVCC） 技术是为了解决问题而生的，通过 MVCC 我们可以解决以下几个问题： 读写之间阻塞的问题：通过 MVCC 可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。 降低了死锁的概率：这是因为 MVCC 没有使用锁，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。 解决一致性读的问题：一致性读也被称为快照读，当我们查询数据库在某个时间点的快照时，只能看到这个时间
MySQL 多版本并发控制 MVCC
lolly1023的博客
01-16 973
MySQL 多版本并发控制 MVCC
MySQL多版本并发控制MVCC实现原理
孟凡霄
04-01 427
承接上文。
MySQL数据库多版本并发控制MVCC
iuu77的博客
02-20 331
MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的 并发控制。这项技术使得在InnoDB的事务隔离级别下执行 一致性读 操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。组成：隐藏字段（rowId+trxId）+undolog+readview隐藏字段（rowId+trxId）
MySQL的多版本并发控制MVCC
02-15 632
博客主页：🏆看看是李XX还是李歘歘🏆 🌺每天不定期分享一些包括但不限于计算机基础、算法、后端开发相关的知识点，以及职场小菜鸡的生活。🌺 💗点关注不迷路，总有一些📖知识点📖是你想要的💗 ⛽️今天的内容是 MySQL的多版本并发控制MVCC ⛽️💻💻💻 数据库并发控制——锁 Multiversion (version) concurrency control (MCC or MVCC) 多版本并发控制 ，它是数据库管理系统一种常见的并发控制。 我们知道并发控制常用...
MVCC多版本并发控制
weixin_42070918的博客
07-12 1403
MVCC（Multi-Version Concurrency Control），即多版本并发控制，在MySQL InnoDB中处理并发时，不加锁和非阻塞并发读，提高并发读性能的一种机制。MVCC维持了数据的多个版本，使得并发读写时没有冲突。
MVCC：多版本并发控制
NorthSmile的博客
07-18 608
MySQL中的MVCC介绍
MySQL多版本并发控制mvcc原理浅析
pyf2533931995的博客
04-19 1317
mvcc(Multi Version Concurrency Control)，多版本并发控制，是一种数据库的并发控制机制。它用于管理事务并发执行时对数据的访问和修改，保证在多个事务同时对数据库进行读写操作，不会出现数据不一致或丢失的情况。
多版本并发控制（MVCC）
勇心在馨
04-30 4117
一、MVCC MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的 并发控制 。这项技术使得在InnoDB的事务隔离级别下执行 一致性读 操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。 二、 快照读与当前读 MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理 读-写
多版本并发控制(MVCC)在分布式系统中的应用
03-02
最近项目中遇到了一个分布式系统的并发控制问题。该问题可以抽象为：某分布式系统由一个数据中心D和若干业务处理中心L1，L2…Ln组成；D本质上是一个key-value存储，它对外提供基于HTTP协议的CRUD操作接口。L的业务...
mysql-线上常用运维sql-2
jll126的博客
06-11 416
在MySQL中，直接查询当前正在执行的事务可能不是非常直观，因为MySQL并没有提供直接的命令或系统视图来列出所有正在运行的事务。但是，你可以通过几种方法间接地获取这些信息。
使用消息队列（MQ）实现MySQL持久化存储与MySQL server has gone away问题解决
最新发布
qq_33665793的博客
06-16 477
而其中一个常见的需求是将消息队列中的数据持久化到数据库中，以确保数据的安全性和可靠性。通过使用消息队列（MQ）将消息持久化存储到MySQL数据库，我们可以提高系统的可靠性和可维护性。它提供了可靠的事务支持和高性能的查询功能。2. 数据可靠性：通过将消息队列中的数据存储到MySQL数据库中，可以确保消息被可靠地处理和传递给消费者。4. 消息消费：编写一个消费者程序，从MQ的队列中获取消息，并将消息存储到MySQL数据库中。5. 消息确认：在成功将消息存储到数据库后，向MQ发送消息确认，告知MQ消息已被处理。
【MySQL】索引（上）
开心星人的博客
06-11 810
索引是一种用于快速查询和检索数据的数据结构，排序好的数据结构。 优点：加快检索速度；通过创建唯一性索引，可以保证行数据的唯一性；通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗 缺点：创建和维护索引需要耗费时间，本身存储也要耗费一定空间不同引擎对索引的支持情况 哈希表、有序数组、B+树、B树、红黑树，二叉树哈希表：只适用于等值查询的场景，用这种索引做不了范围查询，必须全表扫描。查询效率高有序数组：有序数组在等值查询和范围查询场景中的性能就都非常优秀，但是一旦更新数据就得挪动后面的元素，成本太高
深入解析MySQL的层次化设计
m0_66404702的博客
06-14 1082
2、如果是 prepare 状态，检查 binlog 记录的对应事务操作（redo log 与 binlog 记录的事务操作有一个共同字段 XID，redo log 就是通过这个字段找到 binlog 中对应的事务的）是否完整（这点在前面 binlog 三种格式分析过，每种格式记录的事务结尾都有特定的标识），如果完整就将 redo log 设为 commit 状态，然后结束；6、如果表更改，则使用该表的所有高速缓存查询都变为无效并从缓存中删除，这包括使用 MERGE 映射到已更改表的表的查询。
Windows10 MySQL（8.0.37）安装与配置
XLB
06-16 335
新建变量：%MYSQL_HOME%\bin 点击确定，也可以单独在path设置成一条：C:\MySQL\mysql-8.0.37-winx64\bin即可。C:\Mysql\mysql-8.0.37-winx64 （安装路径）工具栏搜索：高级系统设置，或者鼠标右键此电脑>属性>高级系统设置。保存，将my.txt文件后缀改为.ini。编辑my.txt文件，输入以下内容。系统变量找到：Path 点击编辑。解压文件，解压到你想要的位置。(没错就是要点三个确定)新建my.txt文件。点击确定，确定，确定。
MySQL日常问题-行列互换
极客鼠之家
06-13 284
1、表结构和数据2、效果图说明，第一列用户信息stu_no,第二列课程号course_no,第三列课程成绩3、实现SQL。
mysql多版本并发控制mvcc
08-29
- *2* [MySQL数据库多版本并发控制MVCC](https://blog.csdn.net/iuu77/article/details/129132863)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

指挥部在下面

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值