当前位置： 首页 > news >正文

13--MySQL事务管理

news 2025/9/26 16:29:12

一.前言

我们在前面已经介绍过MySQL的CURD操作,但是如果CURD操作不加管理会出现什么问题?

我们的CURD至少要保证以下几点:
1.买票的过程得是原子的

2.买票之间不能相互影响

3.买完票的数据要保存起来

4.买前买之后都要是确定的状态,像这种票数之间变为-1就直接超出了我们的预期

二.事务介绍

1.定义

MySQL 事务（Transaction）是一组原子性的 SQL 操作单元，这些操作要么全部成功执行，要么全部不执行，是一个整体,确保数据库在并发或异常情况下保持一致性.

事务就是要做的或所做的事情，主要用于处理操作量大，复杂度高的数据。

设想一个场景:你要向你的朋友转200元,先确认你的银行卡信息和余额,在你的银行卡里扣200,再确认你朋友的银行卡信息,然后在你朋友的银行卡里加200(这里只是打个比方),这一系列操作构成了一个事务,如果这些操作不是一个整体,那么在你的银行卡里扣了200元,向你朋友银行卡转账的操作失败了,是不是白白亏了200元,肯定是有问题的.

  --这就是事务的必要性,要么全部成功(你少200,朋友多200),要么全部失败(朋友银行卡不加钱,你也不扣钱).

一个 MySQL 数据库，可不止一个事务在运行，同一时刻，甚至有大量的请求被包装成事务，在向 MySQL 服务器发起事务处理请求。而每条事务至少一条 SQL ，最多很多 SQL ,这样如果大家都访问同样的表数据，在不加保护的情况，就绝对会出现问题。甚至，因为事务由多条 SQL 构成，那么，也会存在执行到一半出错或者不想再执行的情况，那么已经执行的怎么办呢？
所以，一个完整的事务，绝对不是简单的 sql 集合

2.特点ACID

原子性（Atomicity）(不可分割性)事务是不可分割的工作单位，要么全部执行成功，要么全部回滚到初始状态。
一致性（Consistency）事务执行前后，数据库从一个一致状态转移到另一个一致状态（如余额不能为负）。
隔离性（Isolation）(独立性)并发事务之间互不干扰，一个事务的操作不会被其他事务看到中间状态。
持久性（Durability）事务提交后，对数据的修改是永久性的，即使系统崩溃也不会丢失。

原子性,隔离性,持久性是因,是为了保证一致性这个果,也就是说我们要通过原子性,隔离性,持久性,配合上用户自身的规范操作,来达成一致性

3.为什么会出现事务

事务被 MySQL 编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的.
备注：我们后面把 MySQL 中的一行信息，称为一行记录

4.事务的版本支持

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务， MyISAM 不支持。


5.查看数据库引擎

show engines;
show engines\G

说明:Engine引擎名称,Support:默认引擎Taranactions:支持事务,Savepoints:支持事务保存点

三.事务的提交方式

分为两种

自动提交

手动提交

查看事务提交方式

show variables like 'autocommit';

这里值为ON说明是打开自动提交的

设置事务提交方式

set autocommit=0; --关闭自动提交
set autocommit=1; --打开自动提交

四.事务的基本操作

简单银行用户表

提前准备

##Centos 7 云服务器，默认开启3306 mysqld服务
sudo netstat -nltp

## 使用win cmd远程访问Centos 7云服务器，mysqld服务(需要win上也安装了MySQL，这里看到结
果即可)
## 注意，使用本地mysql客户端，可能看不到链接效果，本地可能使用域间套接字，查不到链接
C:\Users\whb>mysql -uroot -p -h42.192.83.143
Enter password: ***********
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3484
Server version: 5.7.33 MySQL Community Server (GPL)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
## 使用netstat查看链接情况，可知：mysql本质是一个客户端进程
[whb@VM-0-3-centos ~]$ sudo netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp6 0 0 172.17.0.3:3306 113.132.141.236:19354
ESTABLISHED 30415/mysqld
## 为了便于演示，我们将mysql的默认隔离级别设置成读未提交。
set global transaction isolation level READ UNCOMMITTED;

设置隔离级别之后要重启终端进行查看

创建测试表

create table if not exists account(
id int primary key,
name varchar(50) not null default '',
blance decimal(10,2) not null default 0.0
)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

查看事务是否自动提交(这里为自动提交),看看对手动开启事务和结束事务是否有影响(begin)

show variables like 'autocommit';

操作语法

--开启一个事务,两种方法,这里推荐begin
start transaction;
begin;
--创建一个保存点
savepoint save_name;
--回滚到某个保存点
rollback to save_name;
--回滚到事务开始时
rollback;
--提交事务
commit;  --手动开启的事务必须手动提交

正常演示

这里直接回滚到save1,因为save2在save1之后,所以save2并不存在

非正常演示1

--证明未commit,客户端崩溃,MySQL会自动回滚(隔离级别还是读未提交)

这里没有commit就使用了ctrl+\使得终端A崩溃,可以看到终端B在终端A崩溃前还可以看到表中的数据,在终端A崩溃之后就查不到表中的数据,这就是自动回滚

非正常演示2

--证明commit了，客户端崩溃，MySQL数据不会在受影响，已经持久化

commit的作用就是让数据持久化

非正常演示3

-- 对比试验。证明begin操作会自动更改提交方式，不会受MySQL是否自动提交影响

非正常演示4

-- 证明单条 SQL 与事务的关系

实验1

该实验并没有开启begin且自动提交关闭了

实验2

该实验也没有开启begin且自动提交打开了

发现终端A崩溃后并不影响数据的持久化--autocommit

结论

只要输入begin或者start transaction，事务便必须要通过commit提交，才会持久化，与是否设置set autocommit无关。

事务可以手动回滚，同时，当操作异常，MySQL会自动回滚

对于 InnoDB 每一条 SQL 语言都默认封装成事务，自动提交。（select有特殊情况，因为MySQL 有 MVCC ）

从上面的例子，我们能看到事务本身的原子性(回滚)，持久性(commit)

还有隔离性和一致性没有演示

事务操作注意事项

如果没有设置保存点，也可以回滚，只能回滚到事务的开始。直接使用 rollback(前提是事务还没有提交)

如果一个事务被提交了（commit），则不可以回退（rollback）

可以选择回退到哪个保存点

InnoDB 支持事务， MyISAM 不支持事务

开始事务可以使 start transaction 或者 begin

五.事务的隔离级别

如何理解隔离性1

1.MySQL服务可能会同时被多个客户端进程(线程)访问，访问的方式以事务方式进行一个事务可能由多条SQL构成，也就意味着，任何一个事务，都有执行前，执行中，执行后的阶段。
2.而所谓的原子性，其实就是让用户层，要么看到执行前，要么看到执行后。执行中出现问题,可以随时回滚。所以单个事务，对用户表现出来的特性，就是原子性.
3.毕竟所有事务都要有个执行过程，那么在多个事务各自执行多个SQL的时候，就还是有可能会出现互相影响的情况。比如：多个事务同时访问同一张表，甚至同一行数据。
4.就如同人睡觉一样,你在准备入睡的时候脑子里在想什么,什么睡姿别人并不关心,那么你睡觉在别人看来就是原子的,因为你只有两种状态:睡着了和没睡着.而你睡觉时很容易受到打扰,此时就需要将你的睡觉环境隔离开,保证你在睡觉时不受别人的影响
5.数据库中，为了保证事务执行过程中尽量不受干扰，就有了一个重要特征：隔离性
6.数据库中，允许事务受不同程度的干扰，就有了一种重要特征：隔离级别

隔离级别

读未提交【Read Uncommitted】： 在该隔离级别，所有的事务都可以看到其他事务没有提交的
执行结果。（实际生产中不可能使用这种隔离级别的),相当于没有任何隔离性，也会有很多
并发问题，如脏读，幻读，不可重复读等，我们上面为了做实验方便，用的就是这个隔离性。
读提交【Read Committed】 ：该隔离级别是大多数数据库的默认的隔离级别（不是 MySQL 默
认的）。它满足了隔离的简单定义:一个事务只能看到其他的已经提交的事务所做的改变。这种隔离级别会引起不可重复读，即一个事务执行时，如果多次 select， 可能得到不同的结果。
可重复读【Repeatable Read】： 这是 MySQL 默认的隔离级别，它确保同一个事务，在执行
中，多次读取操作数据时，会看到同样的数据行。但是会有幻读问题。
串行化【Serializable】: 这是事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突，
从而解决了幻读的问题。它在每个读的数据行上面加上共享锁，。但是可能会导致超时和锁竞争
（这种隔离级别太极端，实际生产基本不使用）
隔离级别如何实现：隔离，基本都是通过锁实现的，不同的隔离级别，锁的使用是不同的。常见有，表 锁，行锁，读锁，写锁，间隙锁(GAP),Next-Key锁(GAP+行锁)等。不过，我们目前现有这个认识就行,先关注上层使用。

查看和设置隔离性

-- 查看
SELECT @@global.tx_isolation; --查看全局隔级别
SELECT @@session.tx_isolation; --查看会话(当前)全局隔级别
SELECT @@tx_isolation; --不带global/session参数就默认是session

--设置
--设置当前会话 or 全局隔离级别语法
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ
COMMITTED | REPEATABLE READ | SERIALIZABLE}

设置当前会话隔离性不会影响全局隔离性

设置全局隔离性,另起一个会话隔离性会受到影响

注:如果观察不到现象,重连一下MySQL即可

读未提交【Read Uncommitted】

--几乎没有加锁，虽然效率高，但是问题太多，严重不建议采用

这里终端A并没有提交事务,终端B却能读到终端A未提交的修改信息

--一个事务在执行中，读到另一个执行中事务的更新(或其他操作)但是未commit的数据，这种现象叫做脏读 (dirty read)

读提交【Read Committed】

准备工作

此时还在当前事务中，并未commit，那么就造成了，同一个事务内，同样的读取，在不同的时间段 (依旧还在事务操作中！)，读取到了不同的值，这种现象叫做不可重复读(non reapeatable read

思考:这种现象会带来什么问题?

公司年底要发奖金,根据不同的工作等级发不同奖金,你负责出表格汇总,先查看工作等级为3级的,张三就在里面,你把张三放在了高奖金里面的,这是老板告诉财务,觉得张三干的不是很好,将张三下调到1级的,财务很快修改并提交上去了,此时你也刚好在查看工作等级为1级的,张三又在里面(因为另一个终端提交了修改信息),张三就发了两份奖金.

可重复读【Repeatable Read】

准备工作

在终端B事务开始后,不管终端A如何修改,是否提交,终端B查看到的数据都是一样的,在终端B提交之后(事务结束了),此时才能查看到终端A修改的数据

结论

多次查看，发现终端A在对应事务中insert的数据，在终端B的事务周期中，也没有什么影响，也符合可重复的特点。但是，一般的数据库在可重复读情况的时候，无法屏蔽其他事务insert的数据(为什么？因为隔离性实现是对数据加锁完成的，而insert待插入的数据因为并不存在，那么一般加锁无法屏蔽这类问题),会造成虽然大部分内容是可重复读的，但是insert的数据在可重复读情况被读取出来，导致多次查找时，会多查找出来新的记录，就如同产生了幻觉。这种现象，叫做幻读
(phantom read)。很明显，MySQL在RR级别的时候，是解决了幻读问题的(解决的方式是用Next-Key锁(GAP+行锁)解决的。
前面说的加锁都是指的是行锁,而不是表锁

串行化【Serializable】

准备工作

两个读取之间不会发生阻塞,但是当终端A更新数据或其他操作时,由于终端B也在事务,终端A的操作会阻塞,直至终端B提交操作之后终端A才执行这个更新数据操作

终端A未提交的数据终端B也无法查看,是可重复读的

总结

其中隔离级别越严格，安全性越高，但数据库的并发性能也就越低，往往需要在两者之间找一个平
衡点。
不可重复读的重点是修改和删除：同样的条件, 你读取过的数据,再次读取出来发现值不一样了
幻读的重点在于新增：同样的条件, 第1次和第2次读出来的记录数不一样
说明： mysql 默认的隔离级别是可重复读,一般情况下不要修改
上面的例子可以看出，事务也有长短事务这样的概念。事务间互相影响，指的是事务在并行执行的
时候，即都没有commit的时候，影响会比较大。

一致性(Consistency)


事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。当数据库只包含事务
成功提交的结果时，数据库处于一致性状态。如果系统运行发生中断，某个事务尚未完成而被迫中
断，而改未完成的事务对数据库所做的修改已被写入数据库，此时数据库就处于一种不正确（不一
致）的状态。因此一致性是通过原子性来保证的。
其实一致性和用户的业务逻辑强相关，一般MySQL提供技术支持，但是一致性还是要用户业务逻辑做支撑，也就是，一致性，是由用户决定的。而技术上，通过AID保证C

推荐阅读

如何实现事务的隔离性 - 简书

Innodb中的事务隔离级别和锁的关系 - 美团技术团队

Mysql 间隙锁原理，以及Repeatable Read隔离级别下可以防止幻读原理(百度) - aspirant - 博客园

理解隔离性2

想象一个场景:有一个黑板报,有负责办报的同学,也有观看的同学,观看的同学之间不会相互影响,而写的同学与写的同学之间却不能同时写,写的时候看的同学也看不到

数据库并发的三个场景

--读与读,不存在任何问题,不需要并发访问控制

--写与读,有线程安全问题,可能会造成数据库隔离问题,存在脏读,幻读,不可重复读等问题

--写与写,有线程安全问题,可能更新丢失问题,比如第一类更新,第二类更新问题(后面会讲)

读-写

多版本并发控制（ MVCC ）是一种用来解决 读-写冲突 的无锁并发控制,为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事务ID关联，读操作只读该事务开始前的数据库的快照。 所以 MVCC 可以为数据库解决以下问题
在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数
据库并发读写的性能,同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

前提知识：
3个记录隐藏字段
undo 日志
Read View


3个记录隐藏列字段


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

假设我们有个表结构

mysql> create table if not exists student(
name varchar(11) not null,
age int not null
);
mysql> insert into student (name, age) values ('张三', 28);
Query OK, 1 row affected (0.05 sec)
mysql> select * from student;
+--------+-----+
| name | age |
+--------+-----+
| 张三 | 28 |
+--------+-----+
1 row in set (0.00 sec)
name张三用户姓名（普通数据字段）
age28用户年龄（普通数据字段）
DB_TRX_IDnull创建该记录的事务ID（此处为null，表示未关联事务或记录未被修改）
DB_ROW_ID1隐式主键（InnoDB自动生成的行ID，若未显式定义主键时使用）
DB_ROLL_PTRnull回滚指针（指向undo log中修改前的记录，此处为null表示无历史版本）
DB_TRX_ID（事务ID）
  • 作用：记录创建或最后修改该行的事务ID。
  • 关键点：
    • 在InnoDB的MVCC（多版本并发控制）中，用于判断事务是否可见该记录。
    • 如果事务ID为null，可能表示：
      • 记录未被任何事务修改过（如初始插入后未更新）。
      • 记录在非事务环境下创建（如autocommit=1的简单插入）。
    • 示例场景：
      事务A插入记录时，DB_TRX_ID会被设置为事务A的ID；若事务B后续更新该记录，DB_TRX_ID会更新为事务B的ID。
DB_ROW_ID（隐式主键）
  • 作用：InnoDB自动生成的行唯一标识符。
  • 触发条件：
    • 当表没有显式定义主键（PRIMARY KEY）或唯一索引（UNIQUE KEY）时，InnoDB会隐式添加一个DB_ROW_ID作为聚簇索引。
    • 如果表有主键，则DB_ROW_ID不会生成（主键优先）。
  • 特点：
    • 是一个6字节的自增数字，全局唯一。
    • 该例子中，DB_ROW_ID=1表示这是表中的第一行记录（假设无主键）。
DB_ROLL_PTR（回滚指针）
  • 作用：指向该记录的undo log（回滚日志）中的历史版本。
  • MVCC核心机制：
    • 每次更新记录时，InnoDB会先将旧数据复制到undo log，并更新DB_ROLL_PTR指向undo log中的旧版本。
    • 通过DB_ROLL_PTR，事务可以读取到记录的历史版本，实现非锁定读（如READ COMMITTED或REPEATABLE READ隔离级别）。
  • 示例：
    • 初始记录：DB_ROLL_PTR=null（无历史版本）。
    • 事务A更新age从28→29：
      • 旧值（28）被存入undo log。
      • DB_ROLL_PTR指向undo log中存储旧值的条目。
    • 事务B若需读取事务A修改前的记录，可通过DB_ROLL_PTR找到旧值28。

DB_TRX_ID、DB_ROW_ID、DB_ROLL_PTR是InnoDB实现MVCC和事务隔离的关键隐藏字段。

Read View

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

undo 日志
 

简单理解

MySQL 将来是以服务进程的方式，在内存中运行。我们之前所讲的所有机制：索引，事务，隔离性，日志等，都是在内存中完成的，即在 MySQL 内部的相关缓冲区中，保存相关数据，完成各种判断操作。然后在合适的时候，将相关数据刷新到磁盘当中的。所以，我们这里理解undo log，简单理解成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行。
 

模拟MVCC

现在有一个事务10(仅仅为了好区分)，对student表中记录进行修改(update)：将name(张三)改成
name(李四)。
事务10,因为要修改，所以要先给该记录加行锁。
修改前，现将改行记录拷贝到undo log中，所以，undo log中就有了一行副本数据。(原理就是写
时拷贝)
所以现在 MySQL 中有两行同样的记录。现在修改原始记录中的name，改成 '李四'。并且修改原始
记录的隐藏字段 DB_TRX_ID 为当前 事务10 的ID, 我们默认从 10 开始，之后递增。而原始记录的回滚指针 DB_ROLL_PTR 列，里面写入undo log中副本数据的地址，从而指向副本记录，既表示我的上一个版本就是它。
事务10提交，释放锁。
 

备注：此时，最新的记录是’李四‘那条记录。
现在又有一个事务11，对student表中记录进行修改(update)：将age(28)改成age(38)。
事务11,因为也要修改，所以要先给该记录加行锁。（该记录是李四那条）
修改前，现将改行记录拷贝到undo log中，所以，undo log中就又有了一行副本数据。此时，新的
副本，我们采用头插方式，插入undo log。
现在修改原始记录中的age，改成 38。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前 事务11 的 ID。而原始记录的回滚指针 DB_ROLL_PTR 列，里面写入undo log中副本数据的地址，从而指向副 本记录，既表示我的上一个版本就是它。
事务11提交，释放锁。

这样我们就有了一个基于链表的快照版本链,所谓的回滚就是利用历史数据覆盖当前数据

undo log2.0

undo log就是我们通常说的回滚日志，undo log存放的是数据的历史记录，也可以叫数据的快照。
当一个事务要提交修改时：
1.会用排他锁锁定该行
2.将该行修改前的值Copy到undo log segment（回滚段）。
3.修改当前行的值，将该行的回滚指针指向undo log中修改前的行。

回滚日志使用链表组织起来的，链表的每个节点都是一个数据的版本,InnoDB在每行记录后面添加了三个字段DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID,创建/修改该记录的事务ID,回滚指针,每个版本的回滚指针都指向上一个版本的快照,隐式主键,随着新行插入而单调递增的行ID, 当由innodb自动产生聚集索引时，聚集索引会包括这个行ID的值，否则这个行ID不会出现在任何索引中

read view2.0

前面提到了read view就是快照,我们说undo log中存的是数据的快照->read view是存在undo log中的

每个事务在启动后第一次执行查询时会创建一份快照，一个事务快照的创建过程可以概括为：

  1. 查看当前所有的未提交并活跃的事务，存储在数组中
  2. 选取未提交并活跃的事务中最小的XID，记录在快照的xmin中
  3. 选取未提交事务中最大的XID，记录快照在xmax中

记录这三个信息主要是为了进行可见性判断,即通过ReadView可以知道：哪些事务的提交结果对当前事务可见，哪些事务的提交结果对当前事务不可见。

可见性判断算法

在可重复读隔离级别中，对于当前事务tx_cur来说，tx_cur开始查询之前的已提交事务都对tx_cur都可见，在tx_cur开始查询之前的未提交事务和tx_cur开始查询之后的所有事务对tx_cur均不可见。

read view结构简略版

class ReadView {
// 省略...
private:
/** 高水位，大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id
/** 低水位：小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;
/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;
/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，
* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
// 省略...
};
m_ids; //一张列表，用来维护Read View生成时刻，系统正活跃的事务ID
up_limit_id; //记录m_ids列表中事务ID最小的ID(没有写错)
low_limit_id; //ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的
最大值+1(也没有写错)
creator_trx_id //创建该ReadView的事务ID

我们在实际读取数据版本链的时候，是能读取到每一个版本对应的事务ID的，即：当前记录的
DB_TRX_ID 。
那么，我们现在手里面有的东西就有，当前快照读的 ReadView 和 版本链中的某一个记录的
DB_TRX_ID 。
所以现在的问题就是，当前快照读，应不应该读到当前版本记录。一张图，解决所有问题！


我们已经知道了什么事务可见什么事务不可见,那么既然是可重复读,那么我们每次都要找到同一个快照,这是如何做到的呢?

这要结合undo log来说,undo log将每个版本的快照都记录下来,并构成一个链表

由最新版本不断指向上一个版本,直至最老的版本(最初一版)

1.首先查询行的DB_TRX_ID字段，该字段记录的是当前行最后提交的事务ID，简称为tx_id。
2.通过ReadView判断tx_id是否对tx_cur可见。若可见，即找到了正确版本的数据；若不可见，则通过DB_ROLL_PTR指针找到undo log的上一个版本记录，重复过程1。

思考

如果是`insert`呢？因为`insert`是插入，也就是之前没有数据，那么`insert`也就没有历史版本。但是一般为了回滚操作，insert的数据也是要被放入undo log中，如果当前事务commit了，那么这个undo log 的历史insert记录就可以被清空了。
总结一下，也就是我们可以理解成，`update`和`delete`可以形成版本链，`insert`暂时不考虑。
那么`select`呢？
首先，`select`不会对数据做任何修改，所以，为`select`维护多版本，没有意义。不过，此时有个问题就是：select读取，是读取最新的版本呢？还是读取历史版本？
当前读：读取最新的记录，就是当前读。增删改，都叫做当前读，select也有可能当前读，比如：select lock in share mode(共享锁), select for update （这个好理解，我们后面不讨论）
快照读：读取历史版本(一般而言)，就叫做快照读。(这个我们后面重点讨论)
我们可以看到，在多个事务同时删改查的时候，都是当前读，是要加锁的。那同时有select过来，如果也要读取最新版(当前读)，那么也就需要加锁，这就是串行化。但如果是快照读，读取历史版本的话，是不受加锁限制的。也就是可以并行执行！换言之，提高了效率，即MVCC的意义所在。
那么，是什么决定了，select是当前读，还是快照读呢？隔离级别!
那为什么要有隔离级别呢？
事务都是原子的。所以，无论如何，事务总有先有后。
但是经过上面的操作我们发现，事务从begin->CURD->commit，是有一个阶段的。也就是事务有执行前，执行中，执行后的阶段。但，不管怎么启动多个事务，总是有先有后的。
那么多个事务在执行中，CURD操作是会交织在一起的。那么，为了保证事务的“有先有后”，是不是应该让不同的事务看到它该看到的内容，这就是所谓的隔离性与隔离级别要解决的问题。
先来的事务，应不应该看到后来的事务所做的修改
 

总结
  • 隔离的实现主要有读写锁和MVCC（Multi-Version Concurrency Control）多版本并发处理方式。MVCC方式由于其读写不冲突的方式，相当于读写锁效率更高。
  • undo log和ReadView通过可见性判断算法实现了基本的MVCC，从而实现了事务的隔离。

RR和RC的本质区别

正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同
在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活
跃的其他事务记录起来 此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更 新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可 见;即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因
总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是 同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。正是RC每次快照读，都会形成Read View，所以，RC才会有不可重复读问题。

有个大众误区需要特别强调一下

不可重复读和幻读的区别

很多人容易搞混不可重复读和幻读，确实这两者有些相似。但不可重复读重点在于update和delete，而幻读的重点在于insert。

如果使用锁机制来实现这两种隔离级别，在可重复读中，该sql第一次读取到数据后，就将这些数据加锁，其它事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以当事务A先前读取了数据，或者修改了全部数据，事务B还是可以insert数据提交，这时事务A就会发现莫名其妙多了一条之前没有的数据，这就是幻读，不能通过行锁来避免。需要Serializable隔离级别 ，读用读锁，写用写锁，读锁和写锁互斥，这么做可以有效的避免幻读、不可重复读、脏读等问题，但会极大的降低数据库的并发能力。

所以说不可重复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题。

读-读

不做讨论

写-写

现阶段都认为是当前读,不过多追究

推荐阅读

【MySQL笔记】正确的理解MySQL的MVCC及实现原理_mysqlmvcc实现原理-CSDN博客

详细分析MySQL事务日志(redo log和undo log) - 骏马金龙 - 博客园

【MySQL】InnoDB 如何避免脏读和不可重复读_innodb怎么解决脏读-CSDN博客

http://www.dtcms.com/a/408213.html

相关文章：

  • 微波雷达模块在智能家居中的具体应用案例有哪些？
  • 高手做网站深圳商城网站制作公司
  • 网站目录 自动网站设计学习机构
  • 一个网站上线需要什么百度地图推广怎么做的
  • 大连网络宣传网站做设计英文网站
  • 电子商务网站建设规划课程网站建设目标任务
  • 吴川市规划建设局网站百度关键词快速优化
  • 建一个网站做cpa联盟保亭交通工程建设局网站
  • 鞍山网站设计制作网站wordpress登录qq微信登录界面
  • 自己做视频网站只能用地址连接网页微信版下载不了大文件
  • 小九源码-springboot049-Java物业智慧系统
  • Unity-动画1d混合
  • 网站制作需要多少钱官网wordpress文章幻灯片
  • 网站建设需要哪些技术人员网站建设工作的作用
  • 电商网站怎么做seo通知模板范文
  • 网站建设费入何科目十大免费跨境电商平台
  • 大型门户网站建设哪便宜模板网站怎么修改
  • 基于EasyX的井字棋游戏制作
  • LangChain核心组件之---Chain（链）
  • 网站正在建设中是什么意思百度网站查反链
  • Rust/C/C++ 混合构建 - Cmake集成Cargo编译动态库
  • 松岗网站开发头条热点新闻
  • 如何建设wap网站泉州网站制作多少钱
  • 从转动惯量到惯量张量：深入理解刚体旋转的惯性本质
  • AG-UI协议详解：让智能体与前端无缝对话的事件通信标准
  • 宁波江北区城市建设档案馆网站企业门户网站需求文档
  • 太仓做企业网站网站搭建策略与方法
  • GraphRAG：知识图谱赋能的检索增强生成
  • 幽冥大陆(八)网页wasm汇编语言的作用—东方仙盟化神期
  • centos7.9和rocky8.6 部署MongoDB4.4.18分片集群对比