乐趣区

关于mysql:小胖问我MySQL-事务与-MVCC-原理

jiezi

01 什么是事务？

数据库事务指的是一组数据操作，事务内的操作要么就是全副胜利，要么就是全副失败，什么都不做，其实不是没做，是可能做了一部分然而只有有一步失败，就要回滚所有操作，有点一不做二不休的意思。

在 MySQL 中，事务反对是在引擎层实现的。MySQL 是一个反对多引擎的零碎，但并不是所有的引擎都反对事务。比方 MySQL 原生的 MyISAM 引擎就不反对事务，这也是 MyISAM 被 InnoDB 取代的重要起因之一。

1.1 四大个性

  • 原子性（Atomicity）：事务开始后所有操作，要么全副做完，要么全副不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有产生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质形成的根本单位。
  • 一致性（Consistency）：事务开始前和完结后，数据库的完整性束缚没有被毁坏。比方 A 向 B 转账，不可能 A 扣了钱，B 却没收到。
  • 隔离性（Isolation）：同一时间，只容许一个事务申请同一数据，不同的事务之间彼此没有任何烦扰。比方 A 正在从一张银行卡中取钱，在 A 取钱的过程完结前，B 不能向这张卡转账。
  • 持久性（Durability）：事务实现后，事务对数据库的所有更新将被保留到数据库，不能回滚。

1.2 隔离级别

SQL 事务的四大个性中原子性、一致性、持久性都比拟好了解。但事务的隔离级别的确比拟难的，明天次要聊聊 MySQL 事务的隔离性。

SQL 规范的事务隔离从低到高级别顺次是：读未提交（read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（serializable）。级别越高，效率越低。

  • 读未提交：一个事务还没提交时，它做的变更就能被别的事务看到。
  • 读提交：一个事务提交之后，它做的变更才会被其余事务看到。
  • 可反复读：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。当然在可反复读隔离级别下，未提交变更对其余事务也是不可见的。
  • 串行化：顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。所以种隔离级别下所有的数据是最稳固的，然而性能也是最差的。

1.3 解决的并发问题

SQL 事务隔离级别的设计就是为了能最大限度的解决并发问题：

  • 脏读：事务 A 读取了事务 B 更新的数据，而后 B 回滚操作，那么 A 读取到的数据是脏数据
  • 不可反复读：事务 A 屡次读取同一数据，事务 B 在事务 A 屡次读取的过程中，对数据作了更新并提交，导致事务 A 屡次读取同一数据时，后果不统一。
  • 幻读：系统管理员 A 将数据库中所有学生的问题从具体分数改为 ABCDE 等级，然而系统管理员 B 就在这个时候插入了一条具体分数的记录，当系统管理员 A 改完结后发现还有一条记录没有改过来，就如同产生了幻觉一样，这就叫幻读。

SQL 不同的事务隔离级别能解决的并发问题也不一样，如下表所示：只有串行化的隔离级别解决了全副这 3 个问题，其余的 3 个隔离级别都有缺点。

事务隔离级别 脏读 不可反复读 幻读
读未提交 可能 可能 可能
读已提交 不可能 可能 可能
可反复读 不可能 不可能 可能
串行化 不可能 不可能 不可能

PS：不可反复读的和幻读很容易混同，不可反复读侧重于批改，幻读侧重于新增或删除。解决不可反复读的问题只需锁住满足条件的行，解决幻读须要锁表

1.4 举个栗子

这么说可能有点难以了解，举个栗子。还是之前的表构造以及表数据

CREATE TABLE `student`  (`id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `age` int(11) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 66 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

假如当初，我要同时启动两个食物，一个事务 A 查问 id = 2 的学生的 age，一个事务 B 更新 id = 2 的学生的 age。流程如下，在四种隔离级别下的 X1、X2、X3 的值别离是怎么的呢？

  • 读未提交：X1 的值是 23，因为事务 B 尽管没提交但它的更改已被 A 看到。（如果 B 前面又回滚了 X1 的值就是脏的）。X2、X3 的值也是 23，这无可非议。
  • 读已提交：X1 的值是 22，因为 B 尽管改了，但 A 看不到。（如果 B 前面回滚了，X1 的值不变，解决了脏读），X2、X3 的值是 23，没故障，B 提交了，A 能力看到。
  • 可反复读：X1、X2 都是 22，A 开启的时刻值是 22，那么在 A 的整个过程中，它的值都是 22。（不论 B 在这期间怎么批改，只有 A 还没提交，都是看不见的，解决了不可反复读），而 X3 的值是 23，因为 A 提交了，能看到 B 批改的值了。
  • 串行化：B 在执行更改期间会被锁住，直至 A 提交。B 能力继续执行。（A 在读期间，B 不能写。得保障此时数据是最新的。解决了幻读）所以 X1、X2 都是 22，而最初的 X3 在 B 提交之后执行，它的值就是 23。

那为什么会呈现这样的后果呢？事务隔离级别到底是怎么实现的呢？

事务隔离级别是怎么是实现的呢？我在极客工夫丁奇老师的课上找到了答案：

实际上，数据库外面会创立一个视图，拜访的时候以视图的逻辑后果为准。在“可反复读”隔离级别下，这个视图是在事务启动时创立的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创立的。这里须要留神的是，“读未提交”隔离级别下间接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下间接用加锁的形式来防止并行拜访。

1.5 设置事务隔离级别

不同的数据库默认设置的事务隔离级别也大不一样，Oracle 数据库的默认隔离级别是 读提交 ，而 MySQL 是 可反复读 。所以， 当你的零碎须要把数据库从 Oracle 迁徙到 MySQL 时，请把级别设置成与搬迁之前的（读提交）统一，避免出现不可预测的问题。

1.5.1 查看事务隔离级别

# 查看事务隔离级别
5.7.20 之前
SELECT @@transaction_isolation
show variables like 'transaction_isolation';

# 5.7.20 以及之后
SELECT @@tx_isolation
show variables like 'tx_isolation'

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+

1.5.2 设置隔离级别

批改隔离级别语句格局是：set [作用域] transaction isolation level [事务隔离级别]

其中作用域可选：SESSION（会话）、GLOBAL（全局）；隔离级别就是下面提到的 4 种，不辨别大小写。

例如：设置全局隔离级别为读提交

set global transaction isolation level read committed;

1.6 事务的启动

MySQL 的事务启动有以下几种形式：

  • 显式启动事务语句，begin 或 start transaction。配套的提交语句是 commit，或者回滚语句是 rollback。
# 更新学生名字
START TRANSACTION;
update student set name = '张三' where id = 2;
commit;
  • set autocommit = 0，这个命令会将线程的主动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会主动提交。这个事务继续存在直到你被动执行 commit 或 rollback 语句，或者断开连接。
  • set autocommit = 1，示意 MySQL 主动开启和提交事务。比方执行一个 update 语句，语句只实现后就主动提交了。不须要显示的应用 begin、commit 来开启和提交事务。所以当咱们执行多个语句的时候，就须要手动的用 begin、commit 来开启和提交事务。
  • start transaction with consistent snapshot；下面提到的 begin/start transaction 命令并不是一个事务的终点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，能够应用 start transaction with consistent snapshot 命令。第一种启动形式，一致性视图是在执行第一个快照读语句时创立的；第二种启动形式，一致性视图是在执行 start transaction with consistent snapshot 时创立的。

02 事务隔离的实现

了解了隔离级别，那事务的隔离是怎么实现的呢？要想了解事务隔离，先得理解 MVCC 多版本的并发管制这个概念。而 MVCC 又依赖于 undo log 和 read view 实现。

2.1 什么是 MVCC？

百度上的解释是这样的：

MVCC，全称 Multi-Version Concurrency Control，即多版本并发管制。MVCC 是一种并发管制的办法，个别在数据库管理系统中，实现对数据库的并发拜访，在编程语言中实现事务内存。

MVCC 使得数据库读不会对数据加锁，一般的 SELECT 申请不会加锁，进步了数据库的并发解决能力；数据库写才会加锁。借助 MVCC，数据库能够实现 READ COMMITTED，REPEATABLE READ 等隔离级别，用户能够查看以后数据的前一个或者前几个历史版本，保障了 ACID 中的 I 个性（隔离性)。

MVCC 只在 REPEATABLE READ 和 READ COMMITIED 两个隔离级别下工作。其余两个隔离级别都和 MVCC 不兼容，因为 READ UNCOMMITIED 总是读取最新的数据行，而不是合乎以后事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

2.1.1 InnDB 中的 MVCC

InnDB 中每个事务都有一个惟一的事务 ID，记为 transaction_id。它在事务开始时向 InnDB 申请，依照工夫先后严格递增。

而每行数据其实都有多个版本，这就依赖 undo log 来实现了。每次事务更新数据就会生成一个新的数据版本，并把 transaction_id 记为 row trx_id。同时旧的数据版本会保留在 undo log 中，而且新的版本会记录旧版本的回滚指针，通过它间接拿到上一个版本。

所以，InnDB 中的 MVCC 其实是通过在每行记录前面保留两个暗藏的列来实现的。一列是事务 ID：trx_id；另一列是回滚指针：roll_pt。

2.2 undo log

回滚日志保留了事务产生之前的数据的一个版本，能够用于回滚，同时能够提供多版本并发管制下的读（MVCC），也即非锁定读。

依据操作的不同，undo log 分为两种：insert undo log 和 update undo log。

2.2.1 insert undo log

insert 操作产生的 undo log，因为 insert 操作记录没有历史版本只对以后事务自身可见，对于其余事务此记录不可见，所以 insert undo log 能够在事务提交后间接删除而不须要进行 purge 操作。

purge 的次要工作是将数据库中曾经 mark del 的数据删除，另外也会批量回收 undo pages

所以，插入数据时。它的初始状态是这样的：

2.2.2 update undo log

UPDATE 和 DELETE 操作产生的 Undo log 都属于同一类型：update_undo。（update 能够视为 insert 新数据到原地位，delete 旧数据，undo log 临时保留旧数据）。

事务提交时放到 history list 上，没有事务要用到这些回滚日志，即零碎中没有比这个回滚日志更早的版本时，purge 线程将进行最初的删除操作。

一个事务批改以后数据：

另一个事务批改数据：

这样的同一条记录在数据库中存在多个版本，就是下面提到的多版本并发管制 MVCC。

另外，借助 undo log 通过回滚能够回到上一个版本状态。比方要回到 V1 只须要程序执行两次回滚即可。

2.3 read-view

read view 是 InnDB 在实现 MVCC 时用到的一致性读视图，用于反对 RC（读提交）以及 RR（可反复读）隔离级别的实现。

read view 不是实在存在的，只是一个概念，undo log 才是它的体现。它次要是通过版本和 undolog 计算出来的。作用是决定 事务能看到哪些数据。

每个事务或者语句有本人的一致性视图。一般查问语句是一致性读，一致性读会依据 row trx_id 和一致性视图确定数据版本的可见性。

2.3.1 数据版本的可见性规定

read view 中次要蕴含以后零碎中还有哪些沉闷的读写事务，在实现上 InnDB 为每个事务结构了一个数组，用来保留这个事务启动霎时，以后正 沉闷（还未提交）的事务。

后面说了事务 ID 随工夫严格递增的，把零碎中已提交的事务 ID 的最大值记为数组的低水位，已创立过的事务 ID + 1 记为高水位。

这个视图数组和高水位就组成了以后事务的一致性视图（read view）

这个数组画个图，长这样：

规定如下：

  • 1 如果 trx_id 在灰色区域，表明被拜访版本的 trx_id 小于数组中低水位的 id 值，也即生成该版本的事务在生成 read view 前曾经提交，所以该版本可见，能够被以后事务拜访。
  • 2 如果 trx_id 在橙色区域，表明被拜访版本的 trx_id 大于数组中高水位的 id 值，也即生成该版本的事务在生成 read view 后才生成，所以该版本不可见，不能被以后事务拜访。

  • 3 如果在绿色区域，就会有两种状况：

    • a) trx_id 在数组中，证实这个版本是由还未提交的事务生成的，不可见
    • b) trx_id 不在数组中，证实这个版本是由已提交的事务生成的，可见

第三点我在看教程的时候也有点纳闷，好在有热心网友解答：

落在绿色区域意味着是事务 ID 在低水位和高水位这个范畴外面，而真正是否可见，看绿色区域是否有这个值。如果绿色区域没有这个事务 ID，则可见，如果有，则不可见。在这个范畴外面并不意味着这个范畴就有这个值，比方 [1,2,3,5]，4 在这个数组 1-5 的范畴里，却没在这个数组外面。

这样说可能有点难以了解，我假如一个场景：三个事务对同一条数据进行查问更新等操作，为此画了张图以不便了解：

原始数据还是下图这样的，对 id = 2 的张三进行信息的更新：

针对上图，我想提个问题。别离在 RC（读提交）以及 RR（可反复读）隔离级别下，T4 和 T5 工夫点的查问 age 值别离是多少呢？T4 更新的值又是多少呢？思考片刻，置信大家都有本人的答案。答案在文末，心愿大家能带着本人的疑难持续读上来。

2.3.2 RR（可反复读）下的后果

RR 级别下，查问只抵赖在事务启动前就曾经提交实现的数据，一旦启动事务就会建视图。所以应用 start transaction with consistent snapshot 命令，马上就会建视图。

当初假如：

  • 事务 A 开始前，只有一个沉闷的事务，ID = 2，
  • 已提交的事务也就是插入数据的事务 ID = 1
  • 事务 A、B、C 的事务 ID 别离是 3、4、5

在这种隔离级别下，他们创立视图的时刻如下：

依据上图得，事务 A 的视图数组是[2,3]；事务 B 的视图数组是 [2,3,4]；事务 C 的视图数组是[2,3,4,5]。剖析一波：

  • T4 时刻，B 读数据都是从以后版本读起，过程是这样的：

    • 读到以后版本的 trx_id = 4，刚好是本人，可见
    • 所以 age = 24

  • T5 时刻，A 读数据都是从以后版本读起，过程是这样的：

    • 读到以后版本的 trx_id = 4，比本人视图数组的高水位大，不可见
    • 再往上读到 trx_id = 5，比本人视图数组高水位大，不可见
    • 再往上读到 trx_id = 1，比本人视图数组低水位小，可见
    • 所以 age = 22

这样执行下来，尽管期间这一行数据被批改过，然而事务 A 不管在什么时候查问，看到这行数据的后果都是统一的，所以咱们称之为一致性读。

其实视图是否可见次要看创立视图和提交的机会，总结下法则：

  • 版本未提交，不可见
  • 版本已提交，但在视图创立后提交，不可见
  • 版本已提交，但在视图创立前提交，可见

2.3.2.1 快照读和以后读

事务 B 的 update 语句，如果依照上图的一致性读，如同后果不大对？

如下图周明，B 的视图数组是学生成的，之后事务 C 才提交。那就应该看不见 C 批改的 age = 23 呀？最初 B 怎么得出 24 了？

没错，如果 B 在更新之前执行查问语句，那返回的后果必定是 age = 22。问题是 更新就不能在历史版本更新了呀，否则 C 的更新不就失落了？

所以，更新有个规定：更新数据都是先读后写（读是更新语句执行，不是咱们手动执行），读的就是以后版本的值，叫以后读；而咱们一般的查问语句就叫快照读。

因而，在更新时，以后读读到的是 age = 23，更新之后就成 24 啦。

2.3.2.2 select 以后读

除了更新语句，查问语句如果加锁也是以后读。如果把事务 A 的查问语句 select age from t where id = 2 改一下，加上锁（lock in mode 或者 for update），也都能够失去以后版本 4 返回的 age = 24

上面就是加了锁的 select 语句：

select age from t where id = 2 lock in mode;
 select age from t where id = 2 for update;

2.3.2.3 事务 C 不马上提交

假如事务 C 不马上提交，然而 age = 23 版本已生成。事务 B 的更新将会怎么走呢？

事务 C 还没提交，写锁还没开释，然而事务 B 的更新必须要以后读且必须加锁。所以事务 B 就阻塞了，必须等到事务 C 提交，开释锁能力持续以后的读。

2.3.3 RC（读提交）下的后果

在读提交隔离级别下，查问只抵赖在语句启动前就曾经提交实现的数据；每一个语句执行之前都会从新算出一个新的视图。

留神：在上图的表格中用于启动事务的是 start transaction with consistent snapshot 命令，它会创立一个继续整个事务的视图。所以，在 RC 级别下，这命令其实不起作用。等效于一般的 start transaction（在执行 sql 语句之前才算是启动了事务 ）。 所以，事务 B 的更新其实是在事务 C 之后的，它还没真正启动事务，而 C 已提交。

当初假如：

  • 事务 A 开始前，只有一个沉闷的事务，ID = 2，
  • 已提交的事务也就是插入数据的事务 ID = 1
  • 事务 A、B、C 的事务 ID 别离是 3、4、5

在这种隔离级别下，他们创立视图的时刻如下：

依据上图得，事务 A 的视图数组是[2,3,4]，但它的高水位是 6 或者更大（已创立事务 ID + 1）；事务 B 的视图数组是 [2,4]；事务 C 的视图数组是 [2,5]。剖析一波：

  • T4 时刻，B 读数据都是从以后版本读起，过程是这样的：

    • 读到以后版本的 trx_id = 4，刚好是本人，可见
    • 所以 age = 24

  • T5 时刻，A 读数据都是从以后版本读起，过程是这样的：

    • 读到以后版本的 trx_id = 4，在本人一致性视图范畴内但蕴含 4，不可见
    • 再往上读到 trx_id = 5，在本人一致性视图范畴内但不蕴含 5，可见
    • 所以 age = 23

03 伟人的肩膀

  • cnblogs.com/wyaokai/p/10921323.html
  • time.geekbang.org/column/article/70562
  • zhuanlan.zhihu.com/p/117476959
  • cnblogs.com/xd502djj/p/6668632.html
  • blog.csdn.net/article/details/109044141
  • blog.csdn.net/u014078930/article/details/99659272

04 总结

本文具体聊了事务的方方面面，比方：四大个性、隔离级别、解决的并发问题、如何设置、查看隔离级别、如何启动事务等。除此以外，还深刻理解了 RR 和 RC 两个级别的隔离是怎么实现的？包含详解 MVCC、undo log 和 read view 是怎么配合实现 MVCC 的。最初还聊了快照读、以后读等等。能够说，事务相干的知识点都在这了。看完这一篇还不懂的话，你来捶我呀！

好啦，以上就是狗哥对于数据库事务的总结。感激各技术社区大佬们的付出，尤其是极客工夫，真的牛逼。如果说我看得更远，那是因为我站在你们的肩膀上。心愿这篇文章对你有帮忙，咱们下篇文章见~

05 送点书

如果看到这里，喜爱这篇文章的话，请帮点个难看。微信搜寻 一个优良的废人 ，关注后回复 电子书 送你 1000+ 本编程电子书，包含 C、C++、Java、Python、GO、Linux、Git、数据库、设计模式、前端、人工智能、面试相干、数据结构与算法以及计算机根底，详情看下图。回复 1024 送你一套残缺的 java 视频教程。

退出移动版