导言

本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！

众所周知，MySQL数据库的核心功能便是存储数据，一般是整个业务体系中最重要的一层，可谓是整个体系的“大本营”，因而只需MySQL存在些许危险问题，关于整个体系而言都是丧命的。那此刻不妨考虑一个问题：

MySQL在接受外部数据写入时，有没有或许会发生问题呢？

有人或许会笑着回答：“那怎样或许啊，MySQL在写入数据时怎样会存在问题呢”。

确实，MySQL自身在写入数据时并不会有问题，就算部署MySQL的机器断电/宕机，其内部也有一套健全的机制保证数据不丢掉。但往往危险并不来自于表象，尽管MySQL写入数据没问题，但结合业务来看就会有一个很大的危险，此话怎讲呐？先看事例：

-- 从库存表中扣减商品数量
UPDATE `zz_inventory` SET ......;
-- 向订单表、订单概况表中刺进订单记载
INSERT INTO `zz_order` VALUES(....);
INSERT INTO `zz_order_info` VALUES(....);
-- 向物流表中刺进相应的物流信息
INSERT INTO `zz_logistics` VALUES(....);

上述的伪SQL中，描绘的是一个经典下单业务，先扣库存数量、再增加订单记载、再刺进物流信息，按照正常的逻辑来看，上面的SQL也没有问题。可是请细心想想！实践的项目中，这三组SQL是会由客户端（Java线程）一条条发过来的，假定履行到「增加订单记载」时，Java程序那儿抛出了反常，会呈现什么问题呢？

乍一想好像没问题，但细心一想：Java线程履行时呈现反常会导致线程履行中断。

由于Java线程中断了，所以线程不会再向数据库发送「增加订单概况记载、刺进物流信息」的SQL，此刻再来想想这个场景，由于增加订单概况和物流信息的SQL都未发送过来，因而必然也不会履行，但此刻库存现已扣了，用户钱也付了，但却没有订单和物流信息，这引发的成果估计老板都能杀个程序员祭天了……

其实上面列举的这个事例，在数据库中被称之为业务问题，接下来一同聊一聊。

一、业务的ACID准则

什么是业务呢？业务一般是由一个或一组SQL组成的，组成一个业务的SQL一般都是一个业务操作，例如前面聊到的下单：「扣库存数量、增加订单概况记载、刺进物流信息」，这一组SQL就能够组成一个业务。

而数据库的业务一般也要求满意ACID准则，ACID是联系型数据库完结业务机制时必需求遵守的准则。

ACID首要包括四条准则，即：

  • A/Atomicity：原子性
  • C/Consistency：共同性
  • I/Isolation：独立性/阻隔性
  • D/Durability：耐久性

那这四条准则别离是什么意思呢？接下来一同聊一聊。

1.1、Atomicity原子性

原子性这个概念，在之前《并发编程系列-JMM内存模型》时曾初度提到过，而在MySQL中原子性的意义也大致相同，指组成一个业务的一组SQL要么悉数履行成功，要么悉数履行失利，业务中的一组SQL会被当作一个不行分割的全体，当成一个操作看待。

好比业务A由①、②、③条SQL组成，那这一个业务中的三条SQL有必要悉数履行成功，只需其间恣意一条履行失利，例如②履行时呈现反常了，此刻就会导致业务A中的一切操作悉数失利。

1.2、Consistency共同性

共同性也比较好了解，也便是不论业务发生的前后，MySQL中本来的数据改动都是共同的，也便是DB中的数据只答应从一个共同性状况改动为另一个共同性状况。这句话好像听起来有些绕，不太好了解对嘛？简略解释一下便是：一个业务中的一切操作，要么一同改动数据库中的数据，要么都不改动，关于其他业务而言，数据的改动是共同的，上栗子：

假定此刻有一个业务A，这个业务隶归于一个下单操作，由「⓵扣库存数量、⓶增加订单概况记载、⓷刺进物流信息」三这条SQL操作组成。

共同性的意义是指：在这个业务履行前，数据库中的数据是处于共同性状况的，而SQL履行完结之后业务提交，数据库中的数据仍旧处于一个“共同性”状况，也便是库存数量+订单数量永远是等于开始的库存总数的，比方本来的总库存是10000个，此刻库存剩下8888个，那也就代表着必需求有1112条订单数据才行。

这也便是前面说的：“业务发生的前后，MySQL中本来的数据改动都是共同的”，这句话的意义，不行能库存减了，但订单没有增加，这样就会导致数据库全体数据呈现不共同。

假如呈现库存减了，但订单没有增加的状况，就代表着业务履行进程中呈现了反常，此刻MySQL就会运用业务回滚机制，将之前减的库存再加回去，保证数据的共同性。

但来考虑一个问题，假如业务履行进程中，刚减完库存后，MySQL所在的服务器断电了咋整？好像无法运用业务回滚机制去保证数据共同性了撒？关于这点大可不必忧虑，由于MySQL宕机重启后，会经过分析日志的方法康复数据，保证共同性（关于这点稍后再细聊）。

1.3、Isolation独立性/阻隔性

简略了解原子性和共同性后，再来看看ACID中的阻隔性，在有些地方也称之为独立性，意思便是指多个业务之间都是独立的，相当于每个业务都被装在一个箱子中，每个箱子之间都是离隔的，相互之间并不影响，相同上个栗子：

假定数据库的库存表中，库存数量剩下8888个，此刻有A、B两个并发业务，这两个业务都是相同的下单操作，由「⓵扣库存数量、增⓶加订单概况记载、⓷刺进物流信息」三这条SQL操作组成。

此刻A、B两个业务一同履行，同一时刻履行减库存的SQL，因而这儿是并发履行的，那两个业务之间是否会互相影响，导致扣的是同一个库存呢？答案是不会，ACID准则中的阻隔性保证了并发业务的次序履行，一个未完结业务不会影响别的一个未完结业务。

阻隔性在底层是怎样完结的呢？根据MySQL的锁机制和MVCC机制做到的（后续《MySQL业务与锁原理篇》再详细去讲）。

1.4、Durability耐久性

相较于之前的原子性、共同性、阻隔性来说，耐久性是ACID准则中最简略了解的一条，耐久性是指一个业务一旦被提交，它会坚持永久性，所更改的数据都会被写入到磁盘做耐久化处理，就算MySQL宕机也不会影响数据改动，由于宕机后也能够经过日志康复数据。

也就相当于你许下一个许诺之后，那你无论遇到什么状况都会保证做到，就算遇到山水洪灾、地球消灭、世界爆炸…..任何状况也好，你都会保证完结你的许诺停止。

二、MySQL的业务机制总述

刚刚说到的ACID准则是数据库业务的四个特性，也能够了解为完结业务的基础理论，那接下来一同看看MySQL所供给的业务机制。在MySQL默许状况下，一条SQL会被视为一个独自的业务，一同也无需咱们手动提交，由于默许是敞开业务主动提交机制的，如若你想要将多条SQL组成一个业务履行，那需求显式的经过一些业务指令来完结。

2.1、手动管理业务

在MySQL中，供给了一系列业务相关的指令，如下：

  • start transaction | begin | begin work：敞开一个业务
  • commit：提交一个业务
  • rollback：回滚一个业务

当需求运用业务时，能够先经过start transaction指令敞开一个业务，如下：

-- 敞开一个业务
start transaction;
-- 第一条SQL句子
-- 第二条SQL句子
-- 第三条SQL句子
-- 提交或回滚业务
commit || rollback;

关于上述MySQL手动敞开业务的方法，信任咱们都不陌生，但咱们有一点应该会存在些许疑问：业务是根据其时数据库衔接而言的，而不是根据表，一个业务能够由操作不同表的多条SQL组成，这句话什么意思呢？看下图：

(七)MySQL事务篇：ACID原则、事务隔离级别及事务机制原理剖析

上面画出了两个数据库衔接，假定衔接A中敞开了一个业务，那后续过来的一切SQL都会被加入到一个业务中，也便是图中衔接A，后边的SQL②、SQL③、SQL④、SQL⑤这四条都会被加入到一个业务中，只需在未曾收到commit/rollback指令之前，这个衔接来的一切SQL都会加入到同一个业务中，因而关于这点要紧记，敞开业务后必定要做提交或回滚处理。

不过在衔接A中敞开业务，是不会影响衔接B的，这也是我说的：业务是根据其时数据库衔接的，每个衔接之间的业务是具备阻隔性的，比方上个实在栗子~

此刻先翻开两个cmd指令行，然后用指令衔接MySQL，或许也能够用Navicat、SQLyog等数据库可视化东西，新建两个查询，如下：

(七)MySQL事务篇：ACID原则、事务隔离级别及事务机制原理剖析

这儿插个小偏门常识：当你在Navicat、SQLyog这类可视化东西中，新建一个查询时，本质上它便是给你建立了一个数据库衔接，每一个新查询都是一个新的衔接。

然后开始在两个查询中编写对应的SQL指令，先在查询窗口①中敞开一个业务：

-- 先查询一次表数据
SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
|       4 | 1111      | 男       | 8888     | 2022-09-17 23:48:29 |
+---------+-----------+----------+----------+---------------------+
-- 敞开业务
start transaction;
-- 修正 ID=4 的姓名为：黑熊
update `zz_users` set `user_name` = "黑熊" where `user_id` = 4;
-- 删去 ID=1 的行数据
delete from `zz_users` where `user_id` = 1;
-- 再次查询一次数据
SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
|       4 | 黑熊      | 男       | 8888     | 2022-09-17 23:48:29 |
+---------+-----------+----------+----------+---------------------+

调查上面的成果，对比敞开业务前后的的表数据查询，在业务中别离修正、删去一条数据后，再次查询表数据时会调查到表数据现已改动，此刻再去查询窗口②中查询表数据：

SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
|       4 | 1111      | 男       | 8888     | 2022-09-17 23:48:29 |
+---------+-----------+----------+----------+---------------------+

在查询窗口②中，也就相当于在第二个衔接中查询数据时，会发现第一个衔接（窗口①）改动的数据并未影响到第二个衔接，啥原因呢？这是由于窗口①中还未提交业务，所以第一个衔接改动的数据不会影响第二个衔接。

其实详细的原因是由于MySQL业务的阻隔机制形成的，但关于这点后续再去分析。

此刻在查询窗口①中，输入rollback指令，让其时业务回滚：

-- 回滚其时衔接中的业务
rollback;
-- 再次查询表数据
SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
|       4 | 1111      | 男       | 8888     | 2022-09-17 23:48:29 |
+---------+-----------+----------+----------+---------------------+

成果很明显，当业务回滚后，之前所做的数据更改操作悉数都会吊销，康复到业务敞开前的表数据。当然，假如不手动敞开业务，履行下述这条SQL会发生什么状况呢？

update `zz_users` set `user_name` = "黑熊" where `user_id` = 4;

会直接修正表数据，而且其他衔接可见，由于MySQL默许将一条SQL视为单个业务，一同默许敞开主动提交业务，也便是上面这条SQL履行完了之后就会主动提交。

-- 检查 主动提交业务 是否敞开
SHOW VARIABLES LIKE 'autocommit';
-- 封闭或敞开主动提交
SET autocommit = 0|1|ON|OFF;

上述的[0/ON]是相同的意思，表示敞开主动提交，[1/OFF]则表示封闭主动提交。

2.2、业务回滚点

在上面简略论述了业务的根本运用，但假定现在有一个业务，由很多条SQL组成，可是我想让其间一部分履行成功后，就算后续SQL履行失利也照样提交，这样能够做到吗？早年面的理论上来看，一个业务要么悉数履行成功，要么悉数履行失利，好像做不到啊，但实践上是能够做到的，这儿需求运用业务的回滚点机制。

在某些SQL履行成功后，但后续的操作有或许成功也有或许失利，但不论成功亦或失利，你都想让前面现已成功的操作收效时，此刻就可在其时成功的方位设置一个回滚点。当后续操作履行失利时，就会回滚到该方位，而不是回滚整个业务中的一切操作，这个机制则称之为业务回滚点。

在MySQL中供给了两个关于业务回滚点的指令：

  • savepoint point_name：增加一个业务回滚点
  • rollback to point_name：回滚到指定的业务回滚点

曾经面的事例来演示效果，如下：

-- 先查询一次用户表
SELECT * FROM `zz_users`;
-- 敞开业务
start transaction;
-- 修正 ID=4 的姓名为：黑熊
update `zz_users` set `user_name` = "黑熊" where `user_id` = 4;
-- 增加一个业务回滚点：update_name
savepoint update_name;
-- 删去 ID=1 的行数据
delete from `zz_users` where `user_id` = 1;
-- 回滚到 update_name 这个业务点
rollback to update_name;
-- 再次查询一次数据
SELECT * FROM `zz_users`;
-- 提交业务
COMMIT;

上述代码中敞开了一个业务，业务中总共修正和删去两条SQL组成，然后在修正句子后边增加了一个业务回滚点update_name，在删去句子后回滚到了前面增加的回滚点。

但要留意：回滚到业务点后不代表着业务完毕了，仅仅业务内发生了一次回滚，假如要完毕其时这个业务，还仍旧需求经过commit|rollback;指令处理。

其实借助业务回滚点，能够很好的完结失利重试，比方对业务中的每个SQL增加一个回滚点，当履行一条SQL时失利了，就回滚到上一条SQL的业务点，接着再次履行失利的SQL，反复履行到一切SQL成功停止，最终再提交整个业务。

当然，这个仅仅理论上的假定，实践业务中不要这么干~

2.3、MySQL业务的阻隔机制

OK~，在前面做的小测试中，咱们会发现不同的数据库衔接中，一个衔接的业务并不会影响其他衔接，其时也稍微的提过一嘴：这是根据业务阻隔机制完结的，那接下来重点聊一聊MySQL的业务阻隔机制。其实在MySQL中，业务阻隔机制分为了四个等级：

  • ①Read uncommitted/RU：读未提交
  • ②Read committed/RC：读已提交
  • ③Repeatable read/RR：可重复读
  • ④Serializable：序列化/串行化

上述四个等级，越靠后并发控准则越高，也便是在多线程并发操作的状况下，呈现问题的几率越小，但对应的也功能越差，MySQL的业务阻隔等级，默许为第三等级：Repeatable read可重复读，但如若想要真实了解这几个阻隔等级，得先了解几个由于并发操作形成的问题。

2.3.1、脏读、幻读、不行重复读问题

数据库的脏读问题

首要来看看脏读，脏读的意思是指一个业务读到了其他业务还未提交的数据，也便是其时业务读到的数据，由于还未提交，因而有或许会回滚，如下：

(七)MySQL事务篇：ACID原则、事务隔离级别及事务机制原理剖析

比方上图中，DB衔接①/业务A正在履行下单业务，现在扣减库存、增加订单两条SQL现已完结了，恰巧此刻DB衔接②/业务B跑过来读取了一下库存剩下数量，就将业务A现已扣减之后的库存数量读回去了。但好巧不巧，业务A在增加物流信息时，履行反常导致业务A悉数回滚，也便是本来扣的库存又会增加回去。

在个事例中，业务A先扣减了库存，然后业务回滚时又加了回去，但衔接②现已将扣减后的库存数量读回去操作了，这个进程就被称为数据库脏读问题。这个问题很严重，会导致整个业务体系呈现问题，数据终究紊乱。

数据库的不行重复读问题

再来看看不行重复读问题，不行重复读问题是指在一个业务中，屡次读取同一数据，先后读取到的数据不共同，如下：

(七)MySQL事务篇：ACID原则、事务隔离级别及事务机制原理剖析

你没看错，便是对前面那张图稍微做了一点改造，业务A履行下单业务时，由于增加物流信息的时分出错了，导致整个业务回滚，业务回滚完结后，业务A就完毕了。但业务B却并未完毕，在业务B中，在业务A履行时读取了一次剩下库存，然后在业务回滚后又读取了一次剩下库存，细心想想：B业务第一次读到的剩下库存是扣减之后的，第2次读到的剩下库存则是扣减之前的（由于A业务回滚又加回去了）。

在上述这个事例中，同一个业务中读取同一数据，成果却并不共同，也就阐明了该数据存在不行重复读问题，这样说好像有些绕，那再结合可重复读来一同了解：
可重复读的意思是：在同一业务中，不论读取多少次，读到的数据都是相同的。

结合上述可重复读的界说，再去了解不行重复读问题会简略很多，重点是了解可重复、不行重复这个词义，为了更形象化一点，举个日子中的事例：

一张卫生纸，我先拿去擦了一下桌子上的污水渍，然后又放回了原位，当我想上厕所再次拿起时，它现已无法运用了，这就代表着一张卫生纸是不行重复运用的。

一个大铁锤，我先拿去敲一下松掉的桌腿，然后放回了原位，当我又想敲一下墙上的钉子再次拿起时，这个大铁锤是没有发生任何改动的，能够再次用来敲钉子，这就代表大铁锤是能够重复运用的。

信任结合这两个栗子，更能让你了解可重复与不行重复的概念界说。

数据库的幻读问题

关于幻读的解释在网上也有很多资料，但大部分资料是这样描绘幻读问题的：

幻读：指同一个业务内屡次查询回来的成果集不相同。比方同一个业务A，在第一次查询表的数据行数时，发现表中有n条行记载，可是第2次以同等条件查询时，却发现有n+1条记载，这就好像发生了错觉。

这个说法实践上并不谨慎，第一次读和第2次读同一数据，成果集并不相同，这其实归于一个不行重复读的问题，而并非幻读问题。那接下来举例阐明一下什么叫做真实的幻读问题，先上图：

(七)MySQL事务篇：ACID原则、事务隔离级别及事务机制原理剖析

做过电商业务的小伙伴都清楚，一般用户购买商品后付的钱会先冻结在平台上，然后由平台在固定的时刻内结算用户款，例如七天一结算、半月一结算等方法，在结算业务中一般都会涉及到核销处理，也便是将一切为「已签收状况」的订单改为「已核销状况」。

此刻假定衔接①/业务A正在履行「半月结算」这个作业，那首要会读取订单表中一切状况为「已签收」的订单，并将其更改为「已核销」状况，然后将用户款打给商家。

但此刻恰巧，某个用户的订单正好到了主动确认收货的时刻，因而在业务A刚刚改完表中订单的状况时，业务B又向表中刺进了一条「已签收状况」的订单并提交了，当业务A完结打款后，再次查询订单表，成果会发现表中还有一条「已签收状况」的订单数据未结算，这就好像发生了错觉相同，这才是真实的幻读问题。

当然，这样讲好像还不是那么令人了解，再举个更通俗易懂的栗子，假定此刻平台要晋级，用户表中的性别字段，本来是以「男、女」的方法保存数据，现在平台晋级后要求改为「0、1」替代。
因而业务A开始更改表中一切数据的性别字段，当担任履行业务A的线程正在更改最终一条表数据时，此刻业务B来了，正好向用户表中刺进了一条「性别=男」的数据并提交了，然后业务A改完本来的最终一条数据后，当再次去查询用户表时，成果会发现表中仍旧还存在一条「性别=男」的数据，好像又跟发生了错觉相同。

经过上述这两个事例，咱们应该能够了解真实的幻读问题，发生幻读问题的原因是在于：别的一个业务在第一个业务要处理的目标数据规模之内新增了数据，然后先于第一个业务提交形成的问题。

数据库脏写问题

其实除开三个读的问题外，还有有一个叫做脏写的问题，也便是多个业务一同操作同一条数据，例如两个业务一同向表中增加一条ID=88的数据，此刻就会形成数据掩盖，或许主键抵触的问题，这个问题也被称之为更新丢掉问题。

2.3.2、业务的四大阻隔等级

在上面连续讲了脏读、不行重复读以及幻读三个问题，那这些问题该怎样处理呢？其实四个业务阻隔等级，处理的实践问题便是这三个，因而一同来看看各等等级离处理了什么问题：

  • ①读未提交：处于该阻隔等级的数据库，脏读、不行重复读、幻读问题都有或许发生。
  • ②读已提交：处于该阻隔等级的数据库，处理了脏读问题，不行重复读、幻读问题仍旧存在。
  • ③可重复读：处于该阻隔等级的数据库，处理了脏读、不行重复读问题，幻读问题仍旧存在。
  • ④序列化/串行化：处于该阻隔等级的数据库，处理了脏读、不行重复读、幻读问题都不存在。

前面提到过，MySQL默许是处于第三等级的，能够经过如下指令检查现在数据库的阻隔等级：

-- 查询方法①
SELECT @@tx_isolation;
-- 查询方法②
show variables like '%tx_isolation%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+

其实数据库不同的业务阻隔等级，是根据不同类型、不同粒度的锁完结的，因而想要真实搞懂阻隔机制，还需求弄了解MySQL的锁机制，业务与锁机制二者之间自身便是相得益彰的联系，锁便是为了处理并发业务的一些问题而存在的，但关于锁的内容在后续的《MySQL锁篇》再细聊，这儿就简略概述一下。

这儿先阐明一点，业务是根据数据库衔接的，数据库衔接在《MySQL架构篇》中曾说过：数据库衔接自身会有一条作业线程来保护，也便是说业务的履行本质上便是作业线程在履行，因而所谓的并发业务也便是指多条线程并发履行。

多线程其实是咱们的老朋友了，在之前的《并发编程系列》中，几乎将多线程的底裤都翻出来了，因而结合多线程视点来看，脏读、不行重复读、幻读这一系列问题，本质上便是一些线程安全问题，因而需求经过锁来处理，而根据锁的粒度、类型，又分出了不同的业务阻隔等级。

读未提交等级

这种阻隔等级是根据「写互斥锁」完结的，当一个业务开始写某一个数据时，别的一个业务也来操作同一个数据，此刻为了防止呈现问题则需求先获取锁资源，只要获取到锁的业务，才答应对数据进行写操作，一同获取到锁的业务具备排他性/互斥性，也便是其他线程无法再操作这个数据。

但尽管这个等级中，写同一数据时会互斥，但读操作却并不是互斥的，也便是当一个业务在写某个数据时，就算没有提交业务，其他业务来读取该数据时，也能够读到未提交的数据，因而就会导致脏读、不行重复读、幻读一系列问题呈现。

可是由于在这个阻隔等级中加了「写互斥锁」，因而不会存在多个业务一同操作同一数据的状况，因而这个等级中处理了前面说到的脏写问题。

读已提交等级

在这个阻隔等级中，关于写操作相同会运用「写互斥锁」，也便是两个业务操作同一数据时，会呈现排他性，而关于读操作则运用了一种名为MVCC多版本并发操控的技能处理，也便是有业务中的SQL需求读取其时业务正在操作的数据时，MVCC机制不会让另一个业务读取正在修正的数据，而是读取上一次提交的数据（也便是读本来的老数据）。

也便是在这个阻隔等级中，根据同一条数据而言，关于写操作会具备排他性，关于读操作则只能读已提交业务的数据，不会读取正在操作但还未提交的业务数据，为了了解仍是简略的说一下其进程，相同有两个业务A、B。

业务A的首要作业是担任更新ID=1的这条数据，业务B中则是读取ID=1的这条数据。 此刻当A正在更新数据但还未提交时，业务B开始读取数据，此刻MVCC机制则会根据表数据的快照创立一个ReadView，然后读取本来表中上一次提交的老数据。然后等业务A提交之后，业务B再次读取数据，此刻MVCC机制又会创立一个新的ReadView，然后读取到最新的已提交的数据，此刻业务B中两次读到的数据并不共同，因而呈现了不行重复读问题。

当然，关于MVCC机制以及锁机制这儿暂时先不打开叙述，后续会开单章解说。

可重复读等级

在这个阻隔等级中，首要便是处理上一个等级中遗留的不行重复读问题，但MySQL仍旧是运用MVCC机制来处理这个问题的，只不过在这个等级的MVCC机制会稍微有些不同。在读已提交等级中，一个业务中每次查询数据时，都会创立一个新的ReadView，然后读取最近已提交的业务数据，因而就会形成不行重复读的问题。

而在可重复读等级中，则不会每次查询时都创立新的ReadView，而是在一个业务中，只要第一次履行查询会创立一个ReadView，在这个业务的生命周期内，一切的查询都会从这一个ReadView中读取数据，然后保证了一个业务中屡次读取相同数据是共同的，也便是处理了不行重复读问题。

尽管在这个阻隔等级中，处理了不行重复读问题，但仍旧存在幻读问题，也便是业务A在对表中多行数据进行修正，比方前面的举例，将性别「男、女」改为「0、1」，此刻业务B又刺进了一条性别为男的数据，当业务A提交后，再次查询表时，会发现表中仍旧存在一条性别为男的数据。

序列化/串行化等级

这个阻隔等级是最高的等级，处于该阻隔等级的MySQL绝不会发生任何问题，由于从它的姓名上就能够得知：序列化意思是将一切的业务按序排队后串行化处理，也便是操作同一张表的业务只能一个一个履行，业务在履行前需求先获取表等级的锁资源，拿到锁资源的业务才能履行，其他业务则陷入阻塞，等待其时业务释放锁。

但这种阻隔等级会导致数据库的功能直线下降，究竟相当于一张表上只能答应单条线程履行了，尽管安全等级最高，能够处理脏写、脏读、不行重复读、幻读等一系列问题，但也是代价最高的，一般线上很少运用。

这种阻隔等级处理问题的思想很简略，之前咱们分析过，发生一系列问题的根本原因在于：多业务/多线程并发履行导致的，那在这个阻隔等级中，直接将多线程化为了单线程，天然也就从本源上避免了问题发生。

是不是非常“银杏花”，尽管我处理不了问题，但我能够直接处理制造问题的人。

稍微提一嘴：其实在RR等级中也能够处理幻读问题，便是运用临键锁（空隙锁+行锁）这种方法来加锁，但详细的仍是放在《MySQL锁篇》详细论述。

2.3.3、业务阻隔机制的指令

简略认识MySQL业务阻隔机制后，接着来看看一些关于业务阻隔机制的指令：

-- 方法①：查询其时数据库的阻隔等级
SELECT @@tx_isolation;
-- 方法②：查询其时数据库的阻隔等级
show variables like '%tx_isolation%';
-- 设置阻隔等级为RU等级（其时衔接收效）
set transaction isolation level read uncommitted;
-- 设置阻隔等级为RC等级（大局收效）
set global transaction isolation level read committed;
-- 设置阻隔等级为RR等级（其时衔接收效）
-- 这儿和上述的那条指令作用相同，是第二种设置的方法
set tx_isolation = 'repeatable-read';
-- 设置阻隔等级为最高的serializable等级（大局收效）
set global.tx_isolation = 'serializable';

上述实践上一眼就能看懂，唯一要留意的在于：假如想要让设置的阻隔等级在大局收效，必定要记住加上global关键字，不然收效规模是其时会话，也便是针关于其时数据库衔接有效，在其他衔接中仍旧是本来的阻隔等级。

三、MySQL的业务完结原理

到这儿停止，一些MySQL业务相关的概念和基础就现已讲了解了，现在重点来聊一聊MySQL业务究竟是怎样完结的呢？先把定论抛出来：MySQL的业务机制是根据日志完结的。为什么是根据日志完结的呢？一同来打开聊一聊。

3.1、正常SQL的业务机制

在前面聊到过的一点：MySQL默许敞开业务的主动提交，而且将一条SQL视为一个业务。那MySQL在何种状况下会将业务主动提交呢？什么状况下又会主动回滚呢？想要弄了解这个问题，首要得回顾一下之前讲过的《SQL履行篇-写入SQL的履行流程》，在讲写入类型SQL的履行流程时，曾讲过一点：恣意一条写SQL的履行都会记载三个日志：undo-log、redo-log、bin-log。

  • undo-log：首要记载SQL的吊销日志，比方现在是insert句子，就记载一条delete日志。
  • redo-log：记载其时SQL归属业务的状况，以及记载修正内容和修正页的方位。
  • bin-log：记载每条SQL操作日志，只需是用于数据的主从复制与数据康复/备份。

在写SQL履行记载的三个日志中，bin-log暂时不需求关怀，这个跟业务机制没联系，重点是undo-log、redo-log这两个日志，其间最重要的是redo-log这个日志。

redo-log是一种WAL(Write-ahead logging)预写式日志，在数据发生更改之前会先记载日志，也便是在SQL履行前会先记载一条prepare状况的日志，然后再履行数据的写操作。

但要留意：MySQL是根据磁盘的，但磁盘的写入速度相较内存而言会较慢，因而MySQL-InnoDB引擎中不会直接将数据写入到磁盘文件中，而是会先写到BufferPool缓冲区中，当SQL被成功写入到缓冲区后，紧接着会将redo-log日志中相应的记载改为commit状况，然后再由MySQL刷盘机制去做详细的落盘操作。

由于默许状况下，一条SQL会被当成一个业务，数据写入到缓冲区后，就代表履行成功，因而会主动修正日志记载为commit状况，后续则会由MySQL的后台线程履行刷盘动作。

举个伪逻辑的比如，例如下述这条刺进SQL的履行进程大致如下：

-- 先记载一条状况为 prepare 的日志
-- 然后履行SQL，在缓冲区中更改对应的数据
INSERT INTO `zz_users` VALUES(5,"黑竹","男","9999","2022-09-24 23:48:29");
-- 写入缓冲区成功后，将日志记载改为 commit状况
-- 回来 [Affected rows: 1]，MySQL后台线程履行刷盘动作

一条SQL句子组成的业务，其履行进程是不是很简略了解~，接着来看看手动敞开业务的完结。

3.2、多条SQL的业务机制

先把前面的事例搬下来，如下：

-- 敞开业务
start transaction;
-- 修正 ID=4 的姓名为：黑熊（本来user_name = 1111）
update `zz_users` set `user_name` = "黑熊" where `user_id` = 4;
-- 删去 ID=1 的行数据
delete from `zz_users` where `user_id` = 1;
-- 提交业务
COMMIT;

比方这段SQL代码履行的进程又是啥样的呢？一同来瞧一瞧：

①当MySQL履行时，碰到start transaction;的指令时，会将后续一切写操作悉数先封闭主动提交机制，也便是后续的一切写操作，不论有没有成功都不会将日志记载修正为commit状况。

②先在redo-log中为第一条SQL句子，记载一条prepare状况的日志，然后再生成对应的吊销日志并记载到undo-log中，然后履行SQL，将要写入的数据先更新到缓冲区。

③再对第二条SQL句子做相同处理，假如有更多条SQL则逐条依次做相同处理….. ，这儿简略的说一下吊销日志长啥样，大致如下：

-- 第一条修正SQL的吊销日志（将修正的姓姓名段从 黑熊 改回 1111）
update `zz_users` set `user_name` = "1111" where `user_id` = 4;
-- 第二条删去SQL的吊销日志（将删去的行数据再次刺进）
INSERT INTO `zz_users` VALUES(1,"熊猫","女","6666","2022-08-14 15:22:01");

④直到碰到了rollback、commit指令时，再对前面的一切写SQL做相应处理：

假如是commit提交业务的指令，则先将其时业务中，一切的SQL的redo-log日志改为commit状况，然后由MySQL后台线程做刷盘，将缓冲区中的数据落入磁盘存储。

假如是rollback回滚业务的指令，则在undo-log日志中找到对应的吊销SQL履行，将缓冲区内更新过的数据悉数复原，由于缓冲区的数据被复原了，因而后台线程在刷盘时，仍旧不会改动磁盘文件中存储的数据。

OK~，其实业务机制的底层完结也并不费事，稍微一推导、一考虑就能想了解的道理。

当然，咱们有兴趣的再去推导一下：业务吊销点是怎样完结的呢？其实也并不难的，略加考虑即能够得到答案。

3.3、业务的康复机制

现在再来考虑一个问题，有没有这么一种或许呢？也便是当SQL履行时，数据还没被刷写到磁盘中，成果数据库宕机了，那数据是不是就丢了啊？究竟本地磁盘中的数据，在MySQL重启后仍旧存在，但缓冲区中还未被刷到磁盘的数据呢？由于缓冲区坐落内存中，所以里面的数据重启是不会存在的撒？

关于这个问题呢实践上并不需求忧虑，由于前面聊到过redo-log是一种预写式日志，会先记载日志再去更新缓冲区中的数据，所以就算缓冲区的数据未被刷写到磁盘，在MySQL重启时，仍旧能够经过redo-log日志从头康复未落盘的数据，然后保证数据的耐久化特性。

当然，有人或许又会问：那假如在记载redo-log日志时，MySQL芭比Q了咋整？假如遇到了这个问题呢，首要得祝贺你，你的命运归于很棒，能碰到这个问题的几率满足你买彩票中五百万了~

打趣归打趣，现在回归话题自身，这个问题总不能让它存在是不？究竟有这个问题关于体系而言也是个危险啊，但细心一考虑，其实这个问题不必多虑，为啥？推导一下。

首要看看前面的那种状况：数据被更新到缓冲区但没刷盘，然后MySQL宕机了，MySQL会经过日志康复数据。这儿要留意的是：数据被更新到缓冲区代表着SQL履行成功了，此刻客户端会收到MySQL回来的写入成功提示，仅仅没有落盘而言，所以MySQL重启后只需求再次落盘即可。

但假如在记载日志的时分MySQL宕机了，这代表着SQL都没履行成功，SQL没履行成功的话，MySQL也不会向客户端回来任何信息，由于MySQL一向没回来履行成果，因而会导致客户端衔接超时，而一般客户端都会有超时补偿机制的，比方会超时后重试，假如MySQL做了热备/灾备，这个重试的时刻满足MySQL重启完结了，因而用户的操作仍旧不会丢掉（关于超时补偿机制，在各大数据库衔接池中是有完结的）。

但如若又有小伙伴纠结：我MySQL也没做热备/灾备这类的计划呐，此刻咋整呢？

假如是这样的状况，那就只能自认倒霉了，究竟MySQL挂了一向不重启，不仅仅其时的SQL会丢掉，后续平台上一切的用户操作都会无响应，这归于体系溃散等级的灾难了，因而只能靠完善体系架构来处理。

四、MySQL业务篇总结

一点点看到这儿，《MySQL业务篇》也就接近了尾声，在本篇中对业务机制一点点去引出，渐渐的到业务机制的概述、并发业务的问题、业务的阻隔等级、业务的完结原理等诸多方面进行了全面分析，但咱们应该也稍微有些不尽兴，究竟关于阻隔等级的详细完结并未讲到，这是由于MySQL业务与锁机制之间有着千丝万缕的联系，所以在《MySQL锁篇》中会再次详细讲到业务阻隔机制的。

当然，由于现在是分布式/微服务架构横行的年代，所以也引出了新的问题，即分布式业务问题，这个问题又需求经过全新的业务机制去处理了，关于这点再讲完《MySQL分库分表》后，会再单开一章《分布式业务篇》去详细论述，这儿头的学问很大~

再次结合undo-log、redo-log日志来看待ACID的四大特性：原子性、共同性、阻隔性、耐久性。

  • 原子性要求业务中一切操作要么悉数成功，要么悉数失利，这点是根据undo-log来完结的，由于在该日志中会生成相应的反SQL，履行失利时会运用该日志来回滚一切写入操作。
  • 耐久性要求的是一切SQL写入的数据都有必要能落入磁盘存储，保证数据不会丢掉，这点则是根据redo-log完结的，详细的完结进程在前面业务康复机制讲过。
  • 阻隔性的要求是一个业务不会受到另一个业务的影响，关于这点则是经过锁机制和MVCC机制完结的，只不过MySQL屏蔽了加锁和MVCC的细节，详细的会在后续章节中细聊。
  • 共同性要求数据库的全体数据改动，只能从一个共同性状况变为另一个共同性状况，其实前面的原子性、耐久性、阻隔性都是为了保证这点而存在的。