共计 4796 个字符，预计需要花费 12 分钟才能阅读完成。
本篇内容介绍了“MySQL 中的事务隔离是什么意思”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的，但并不是所有的引擎都支持事务。比如 MySQL 原生的 MyISAM 引擎就不支持事务。
一、事务的特性
原子性：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏
隔离性：数据库允许多个并发事务同时对数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失
二、隔离级别
1. 当数据库上有多个事务同时执行的时候，就可能出现脏读、不可重复读、幻读的问题
脏读：B 事务读取到了 A 事务尚未提交的数据
不可重复读：一个事务读取到了另一个事务中提交的 update 的数据
幻读 / 虚读：一个事务读取到了另一个事务中提交的 insert 的数据
2. 事务的隔离级别包括：读未提交、读提交、可重复读和串行化
读未提交：一个事务还没提交时，它做的变更就能被别的事务看到
读提交：一个事务提交之后，它做的变更才会被其他事务看到（解决脏读，Oracle 默认的隔离级别）
可重复读：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的，而且未提交变更对其他事务也是不可见的（解决脏读和不可重复读，MySQL 默认的隔离级别）
串行化：对于同一行记录，写会加写锁，读会加读锁，当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行（解决脏读、不可重复读和幻读）
安全性依次提交，性能依次降低
3. 假设数据表 T 中只有一列，其中一行的值为 1
create table T(c int) engine=InnoDB;
insert into T(c) values(1);下面是按照时间顺序执行两个事务的行为：
若隔离级别是读未提交，则 V1 是 2。这时候事务 B 虽然还没提交，但是结果已经被 A 看到了。V2、V3 都是 2
若隔离级别是读提交，则 V1 是 1，V2 是 2。事务 B 的更新在提交后才能被 A 看到。V3 也是 2
若隔离级别是可重复读，则 V1、V2 是 1，V3 是 2。之所以 V2 是 1，遵循的是事务在执行期间看到的数据前后必须是一致的
若隔离级别是串行化，V1、V2 值是 1，V3 是 2
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在读提交隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。读未提交隔离级别下直接返回记录上的最新值，没有视图概念；而串行化隔离级别下直接用加锁的方式来避免并行访问
三、事务隔离的实现（以可重复读为例）
在 MySQL 中，每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值
假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录
当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。如图中看到的，在视图 A、B、C 里面，这一个记录的值分别是 1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。对于 read-viewA，要得到 1，就必须将当前值一次执行图中所有的回滚操作得到
即使现在有另外一个事务正在将 4 改成 5，这个事务跟 read-view A、B、C 对应的事务是不会冲突的
系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除
四、事务启动的方式
MySQL 的事务启动方式有以下几种：
显示启动事务语句，begin 或 start transaction。提交语句是 commit，回滚语句是 rollback
set autocommit=0，这个命令将这个线程的自动提交关掉。意味着如果只执行一个 select 语句，这个事务就启动了，而且不会自动提交事务。这个事务持续存在直到主动执行 commit 或 rollback 语句，或者断开连接
建议使用 set autocommit=1，通过显示语句的方式来启动事务
可以在 information_schema 库中的 innodb_trx 这个表中查询长事务，如下语句查询持续时间超过 60s 的事务
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started)) 60五、事务隔离还是不隔离
下面是一个只有两行的表的初始化语句：
mysql CREATE TABLE `t` ( `id` int(11) NOT NULL,
`k` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);事务 A、B、C 的执行流程如下，采用可重复读隔离级别
begin/start transaction 命令：不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动，一致性视图是在执行第一个快照读语句时创建的
start transaction with consistent snapshot 命令：马上启动一个事务，一致性视图是在执行这条命令时创建的
按照上图的流程执行，事务 B 查到的 k 的值是 3，而事务 A 查到的 k 的值是 1
1、快照在 MVCC 里是怎么工作的？
在可重复读隔离级别下，事务启动的时候拍了个快照。这个快照是基于整个库的，那么这个快照是如何实现的？
InnoDB 里面每个事务有一个唯一的事务 ID，叫做 transaction id。它在事务开始的时候向 InnoDB 的事务系统申请，是按申请顺序严格递增的
每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记作 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。也就是说，数据表中的一行记录，其实可能有多个版本，每个版本有自己的 row trx_id
下图是一个记录被多个事务连续更新后的状态：
语句更新生成的 undo log（回滚日志）就是上图中的是哪个虚线箭头，而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 V2 的时候，就是通过 V4 依次执行 U3、U2 算出来的
按照可重复读的定义，一个事务启动的时候，能够看到所以已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。在实现上，InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前在启动了但还没提交的所有事务 ID。数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。这个视图数组和高水位就组成了当前事务的一致性视图。而数据的可见性规则，就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的
这个视图数组把所有的 row trx_id 分成了几种不同的情况
对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
1）如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的
2）如果落在红色部分，表示这个版本是由将来启动的事务生成的，肯定不可见
3）如果落在黄色部分，那就包括两种情况
若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见
若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见
InnoDB 利用了所有数据都有多个版本的这个特性，实现了秒级创建快照的能力
2、为什么事务 A 的查询语句返回的结果是 k =1？
假设：
1. 事务 A 开始时，系统里面只有一个活跃事务 ID 是 99
2. 事务 A、B、C 的版本号分别是 100、101、102
3. 三个事务开始前，(1,1)这一行数据的 row trx_id 是 90
这样，事务 A 的是数组就是[99,100]，事务 B 的视图数组是[99,100,101]，事务 C 的视图数组是[99,100,101,102]
从上图中可以看到，第一个有效更新是事务 C，从数据从 (1,1) 改成了(1,2)。这时候，这个数据的最新版本的 row trx_id 是 102，而 90 这个版本已经成为了历史版本
第二个有效更新是事务 B，把数据从 (1,2) 改成了(1,3)。这时候，这个数据的最新版本是 101，而 102 又成为了历史版本
在事务 A 查询的时候，其实事务 B 还没提交，但是它生成的 (1,3) 这个版本已经变成当前版本了。但这个版本对事务 A 必须是不可见的，否则就变成脏读了
现在事务 A 要读数据了，它的视图数组是[99,100]。读数据都是从当前版本读起的。所以，事务 A 查询语句的读数据流程是这样的：
找到 (1,3) 的时候，判断出 row trx_id=101，比高水位大，处于红色区域，不可见
接着，找到上一个历史版本，一看 row trx_id=102，比高水位大，处于红色区域，不可见
再往前找，终于找到了(1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见
虽然期间这一行数据被修改过，但是事务 A 不论在什么时候查询，看到这行数据的结果都是一致的，我们称之为一致性读
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
版本未提交，不可见
版本已提交，但是是在视图创建后提交的，不可见
版本已提交，而且是在视图创建前提交的，可见
事务 A 的查询语句的视图数组是在事务 A 启动的时候生成的，这时候：
(1,3)还没提交，属于情况 1，不可见
(1,2)虽然提交了，但是是在视图数组创建之后提交的，属于情况 2，不可见
(1,1)是在视图数组创建之前提交的，可见
3、为什么事务 B 的查询语句返回的结果是 k =3？
事务 B 要去更新数据的时候，就不能再在历史版本上更新了，否则事务 C 的更新就丢失了。因此，事务 B 此时的 set k=k+ 1 是在 (1,2) 的基础上进行的操作
更新数据都是先读后写的，而这个读，只能读当前的值，称为当前读。除了 update 语句外，select 语句如果加锁，也是当前读
假设事务 C 不是马上提交的，而是变成了下面的事务 C’，会怎么样？
上图中，事务 C 更新后没有马上提交，在它提交前，事务 B 的更新语句先发起了。虽然事务 C 还没提交，但是 (1,2) 这个版本也已经生成了，并且是当前的最新版本
这时候涉及到了两阶段锁协议，事务 C 没提交，也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C 释放这个锁，才能继续它的当前读
七、事务的可重复读的能力是怎么实现的？
可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待
而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图
在读提交隔离级别下，每一个语句执行前都会重复算出一个新的视图
“MySQL 中的事务隔离是什么意思”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
