MySQL【11】事务
目录
1.什么是事务
为什么会出现事务
2.事务的版本支持
3. 事务的提交方式
3.1查看事务的提交方式
3.2设置事务的提交方式
4.事务常见操作方式
准备工作：
4.1设置隔离级别
4.2创建测试表
事务操作：
4.3事务常见操作
4.4 非正常演示
4.5 单挑sql与事务的关系
4.6 结论
5.事务的隔离级别
如何理解隔离性：
5.1隔离级别
5.2隔离级别的查看
5.3 设置隔离级别
5.4 读未提交
5.5 读已提交
5.6 可重复读（默认隔离级别 ）
5.7 串行化
5.8 总结
6.一致性
7.MVCC 机制
7.1概念
7.2 记录的隐藏字段
7.3 undo 日志
7.4 模拟MVCC
7.5 当前读和快照读
7.6 Read View 读视图
8. RC 和 RR 的本质区别
8.1当前读和快照读在RR级别下的区别
8.2 RC和RR本质区别
1.什么是事务
事务就是一组DML语句组成，这些语句在逻辑上存在相关性，这一组DML语句要么全部成功，要么全部失败，是一个整体。MySQL提供一种机制，保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。
事务就是要做的或所做的事情，主要用于处理操作量大，复杂度高的数据。假设一种场景：你毕业了，学校的教务系统后台 MySQL 中，不在需要你的数据，要删除你的所有信息(一般不会:) ), 那么要删除你的基本信息(姓名，电话，籍贯等)的同时，也删除和你有关的其他信息，比如：你的各科成绩，你在校表现，甚至你在论坛发过的文章等。这样，就需要多条 MySQL 语句构成，那么所有这些操作合起来，就构成了一个事务。
正如我们上面所说，一个 MySQL 数据库，可不止你一个事务在运行，同一时刻，甚至有大量的请求被包装成事务，在向 MySQL 服务器发起事务处理请求。而每条事务至少一条 SQL ，最多很多 SQL ,这样如果大家都访问同样的表数据，在不加保护的情况，就绝对会出现问题。甚至，因为事务由多条 SQL 构成，那么，也会存在执行到一半出错或者不想再执行的情况，那么已经执行的怎么办呢？所有，一个完整的事务，绝对不是简单的 sql 集合，还需要满足如下四个属性（ACID
）：
- 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性完成预定的工作。
- 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
为什么会出现事务
事务被 MySQL 编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的
2.事务的版本支持
在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务， MyISAM 不支持
查看数据库引擎show engines; # 表格显示 show engines \G # 行显示
- Transactions：该存储引擎是否支持事务。
3. 事务的提交方式
事务的提交方式常见的有两种：自动提交，手动提交。
3.1查看事务的提交方式
使用以下命令就可以直到事务的自动提交有没有被打开：
show variables like 'autocommit';
autocommit值为NO表示被打开了，OFF表示没有被打开，需要手动提交
3.2设置事务的提交方式
set autocommit = 1; # 自动提交 set autocommit = 0; # 手动提交关闭自动提交操作：
打开自动提交：
4.事务常见操作方式
准备工作：
4.1设置隔离级别
为了便于演示，我们将mysql的默认隔离级别设置成读未提交。（读未提交允许一个事务读取另一个事务尚未提交的修改。）
set global transaction isolation level READ UNCOMMITTED;设置完隔离级别之后，当前会话的隔离级别并不会被改变，需要使用
quit命令退出客户端之后，再重新启动，重启之后MySQL的隔离级别才会更新。使用以下命令查看，此时就是读未提交的隔离级别了。
select @@transaction_isolation;
4.2创建测试表
员工工资表
事务操作：
4.3事务常见操作
此时我们是打开了自动提交操作
1.启动事务：begin; 或 start transaction;（启动一个事务，该指令开始往后的所有 sql 都属于同一个事务，直到遇见 commit 为止）
我们开启两个终端，模拟并发访问MySQL的场景
2.设置保存点：savepoint 保存点名称;（在事务中创建指定名称的保存点）
我们在左边设置一个保存点，再插入一条数据；在右边进行查看表数据
3.事务回滚：rollback to 保存点名称;（将事务回滚到指定保存点）rollback;（让事务回滚到最开始）
将事务回滚s2，右边就查看不到第三条记录了
4.提交事务：commit; 提交事务，事务再提交后就无法进行回滚操作。
4.4 非正常演示
证明未commit，客户端崩溃，MySQL自动会回滚（隔离级别设置为读未提交）
由于左边我们一直在做数据的插入，并没有commit，此时客服端崩溃，事务自动回滚，我们在右边查看表数据就查看不到了。
4.5 单挑sql与事务的关系
在某些情况下，单条SQL语句可以作为一个事务的唯一操作。但是，这种情况下的单条SQL仍然具有事务的某些特性，如自动提交（相当于一个只包含一个操作的事务）。
如果自动提交被打开，则单条 sql 语句执行后会自动被提交。如果自动提交被关闭，则 sql 语句在执行后需要手动进行提交。
在autocommit设置为on的情况下，我们不开启事务，只是正常的执行一条sql语句，不进行commit，然后退出左边客户端，然后在右边客户端进行查看，数据并没有被回滚
我们在autocommit设置为OFF的情况下，我们再来重复上面操作，发现数据被回滚了。
4.6 结论
- 只要输入begin或者start transaction，事务便必须要通过commit提交，才会持久化，与是否设置set autocommit无关。
- 事务可以手动回滚，同时，当操作异常，MySQL会自动回滚
- 对于 InnoDB 每一条 SQL 语言都默认封装成事务，自动提交。（select有特殊情况，因为MySQL 有 MVCC ）
- 从上面的例子，我们能看到事务本身的原子性(回滚)，持久性(commit)
5.事务的隔离级别
如何理解隔离性：
- MySQL服务可能会同时被多个客户端进程(线程)访问，访问的方式以事务方式进行
- 一个事务可能由多条SQL构成，也就意味着，任何一个事务，都有执行前，执行中，执行后的阶段。而所谓的原子性，其实就是让用户层，要么看到执行前，要么看到执行后。执行中出现问题，可以随时回滚。所以单个事务，对用户表现出来的特性，就是原子性。
- 但，毕竟所有事务都要有个执行过程，那么在多个事务各自执行多个SQL的时候，就还是有可能会出现互相影响的情况。比如：多个事务同时访问同一张表，甚至同一行数据。
- 就如同你妈妈给你说：你要么别学，要学就学到最好。至于你怎么学，中间有什么困难，你妈妈不关心。那么你的学习，对你妈妈来讲，就是原子的。那么你学习过程中，很容易受别人干扰，此时，就需要将你的学习隔离开，保证你的学习环境是健康的。
- 数据库中，为了保证事务执行过程中尽量不受干扰，就有了一个重要特征：隔离性
- 数据库中，允许事务受不同程度的干扰，就有了一种重要特征：隔离级别
5.1隔离级别
- 读未提交 (Read Uncommitted )：事务的最低隔离级别，该隔离级别下，所有的事务都可以看到其他事务没有提交的执行结果，实际生产中不可能使用这种隔离级别，因为这种隔离级别相当于没有任何隔离性，会存在很多并发问题，如脏读、幻读、不可重复读等。
- 读提交 (Read Committed)：该隔离级别是大多数数据库的默认隔离级别，但它不是MySQL默认的隔离级别，它满足了隔离的简单定义，即一个事务只能看到其他已经提交的事务所做的改变，但这种隔离级别存在不可重复读和幻读的问题。
- 可重复读 (Repeatable Read)：MySQL 默认的隔离级别，该隔离级别确保同一个事务在执行过程中，多次读取操作数据时会看到同样的数据，即解决了不可重复读的问题，但这种隔离级别下仍然存在幻读的问题。
- 串行化 (Serializable)：事务的最高隔离级别，将所有到来的 CURD 操作按照先后顺序挨个执行，从而解决了幻读问题。它在每个读的数据行上面加上共享锁，但是可能会导致超时和锁竞争问题，这种隔离级别太极端，实际生成中基本不使用。
5.2隔离级别的查看
查看全局的隔离级别：
select @@global.transaction_isolation;查看会话隔离级别：登录时会默认拷贝一份全局隔离级别给会话的隔离界别。
select @@session.transaction_isolation; select @@transaction_isolation;
5.3 设置隔离级别
设置全局隔离级别：会影响后续的所有客户端，必须将设置该隔离界别的会话重启才会生效。
set global transaction isolation level {read uncommitted / read committed / repeatable read / serializable};设置会话隔离级别：只会影响当前会话的隔离级别，不需要重启会话即可生效。
set session transaction isolation level {read uncommitted / read committed / repeatable read / serializable};我们设置会话隔离级别为：读提交，只有会话的隔离级别发生变化，全局隔离级别没变化。
5.4 读未提交
事务的最低隔离级别，该隔离级别下，所有的事务都可以看到其他事务没有提交的执行结果。
一个事务在执行中，读到另一个执行中事务的更新(或其他操作)但是未commit的数据，这种现象叫做脏读(dirty read)
5.5 读已提交
一个事务只能看到其他已经提交的事务所做的改变，但这种隔离级别存在不可重复读。
不可重复读是指在同一个事务中，对同一行数据执行两次或多次读取操作时，读取到的数据值可能不同。这种情况通常发生在其他事务在这两次读取之间修改了该数据。就比如，其他事务刚好在该事务两次读取之间，进行了commit，那么commit前后的查询结果都不一样，这种现象就称之为不可重复读。
例子：
先将两个客户端都设置成读已提交
左客户端的事务在未提交前，右客户端无法查看左客户端所做的操作。
当左客户端使用 commit 将事务提交之后，右客户端才能看到其对数据的操作。
5.6 可重复读（默认隔离级别 ）
即使事务 A 使用 commit 提交事务了，事务 B 也无法查看到 A 的操作，只有重启一个新的事务才能看到。
该隔离级别确保同一个事务在执行过程中，多次读取操作数据时会看到同样的数据，即解决了不可重复读的问题，但这种隔离级别下仍然存在幻读的问题。
幻读指的是一个事务在前后两次查询同一个范围时，后一次查询看到了前一次查询没有看到的数据行。这些新增的数据行就像“幻影”一样突然出现，因此被称为幻读。
eg:
启动两个客户端，隔离级别设置成可重复读
两个客户端启动事务，我们向左边插入数据，右边进行查看。（可以看到，左边没有commit，右边是看不到的。）
左边commit，右边进行查看，发现数据仍然没有变化）
我们让右边也commit，这才能看的到左边新增的数据。
结论：在可重复读的隔离级别下，两个事务在运行期间，互不影响。
多次查看，发现终端A在对应事务中insert的数据，在终端B的事务周期中，也没有什么影响，也符合可重复的特点。但是，一般的数据库在可重复读情况的时候，无法屏蔽其他事务insert的数据(为什么？因为隔离性实现是对数据加锁完成的，而insert待插入的数据因为并不存在，那么一般加锁无法屏蔽这类问题),会造成虽然大部分内容是可重复读的，但是insert的数据在可重复读情况被读取出来，导致多次查找时，会多查找出来新的记录，就如同产生了幻觉。这种现象，叫做幻读(phantom read)。很明显，MySQL在RR级别的时候，是解决了幻读问题的(解决的方式是用Next-Key锁(GAP+行锁)解决的。
5.7 串行化
最高隔离级别，会将到来的所有事务按照到达的先后顺序挨个执行，极大的影响了效率，不推荐使用该隔离级别。
eg:
启动两个客户端，隔离级别设置成串行化 serializable。
在该级别下，如果两个事务都进行读操作，则这连个事务可以并发执行，不会被阻塞。
在存在多个事务的情况下，一旦有事务进行插入操作，则立马会被阻塞。
只有等到其它事务commit后，该事务插入操作才会被执行
5.8 总结
- 其中隔离级别越严格，安全性越高，但数据库的并发性能也就越低，往往需要在两者之间找一个平衡点。
- 不可重复读的重点是修改和删除：同样的条件, 你读取过的数据,再次读取出来发现值不一样了幻读的重点在于新增：同样的条件, 第1次和第2次读出来的记录数不一样
- 说明： mysql 默认的隔离级别是可重复读,一般情况下不要修改
- 上面的例子可以看出，事务也有长短事务这样的概念。事务间互相影响，指的是事务在并行执行的时候，即都没有commit的时候，影响会比较大。
6.一致性
- 事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。当数据库只包含事务成功提交的结果时，数据库处于一致性状态。如果系统运行发生中断，某个事务尚未完成而被迫中断，而改未完成的事务对数据库所做的修改已被写入数据库，此时数据库就处于一种不正确（不一致）的状态。因此一致性是通过原子性来保证的。
- 其实一致性和用户的业务逻辑强相关，一般MySQL提供技术支持，但是一致性还是要用户业务逻辑做支撑，也就是，一致性，是由用户决定的。
- 而技术上，通过AID保证C（有了原子性，隔离性，永久性后，就保证了一致性）
7.MVCC 机制
- 读-读 ：不存在任何问题，也不需要并发控制
- 读-写 ：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
- 写-写 ：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失(后面补充)
7.1概念
MVCC即多版本并发控制，是一种用来解决读-写冲突的无锁并发控制。
MySQL 会为事务分配单项增长的事务 id，为每个修改保存一个版本，将版本与事务 id 关联起来，读操作只读该事务开始前的数据库快照。（每个事务都要有自己的事务 ID，可以根据事务 ID 的大小，来决定事务到来的先后顺序)
所以MVCC可以解决以下问题：
- 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
- 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题
事务管理：
- MySQL 的服务端 (mysqld) 可能会面临处理多个事务的情况，事务也有自己的生命周期，mysqld 也要对多个事务进行管理，因此在 mysqld 中，事务一定是对应的一个或者一套结构体 / 类对象。
- 事务也要有自己的结构体，事务 ID 对应的就是每个事务的结构体对象。当到达一个事务时，MySQL 会先 new 出一个事务的对象，再给该对象原子性的申请一个事务 ID，最后用事务 ID 初始化这个事务的结构体对象。
- 将多个事务的结构体对象使用某种数据结构管理组织起来，组织好之后就成了对对应数据结构的增删查改。
7.2 记录的隐藏字段
- DB_TRX_ID ：6 byte，最近修改( 修改/插入 )事务ID，记录创建这条记录/最后一次修改该记录的事务ID
- DB_ROLL_PTR : 7 byte，回滚指针，指向这条记录的上一个版本（简单理解成，指向历史版本就行，这些数据一般在 undo log 中）
- DB_ROW_ID : 6 byte，隐含的自增ID（隐藏主键），如果数据表没有主键， InnoDB 会自动以DB_ROW_ID 产生一个聚簇索引
补充：实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了
eg:创建如下学生表
向表中插入一条数据
上面描述的意思是：
name age DB_TRX_ID(创建该记录的事
务ID)DB_ROW_ID(隐式
主键)DB_ROLL_PTR(回滚
指针)张三 28 null 1 null 我们目前并不知道创建该记录的事务ID，隐式主键，我们就默认设置成null，1。第一条记录也没有其他版本，我们设置回滚指针为null。
7.3 undo 日志
MySQL 将来是以服务进程的方式，在内存中运行。
我们之前所讲的所有机制：索引，事务，隔离性，日志等，都是在内存中完成的，即在 MySQL 内部的相关缓冲区中，保存相关数据，完成各种判断操作。然后在合适的时候，将相关数据刷新到磁盘当中的。
所以，我们这里理解undo log，简单理解成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行
7.4 模拟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提交，释放锁。
这样，我们就有了一个基于链表记录的历史版本链。所谓的回滚，无非就是用历史数据，覆盖当前数据。
上面的一个一个版本，我们可以称之为一个一个的快照。
7.5 当前读和快照读
- 当前读：访问当前最新的记录被称之为当前读，增删改操作必须得是当前读，需要加锁
- 快照读：访问版本链中的历史记录被称之为快照读，事务在 select 时当前读和快照都有可能进行，如果是当前读，那么也需要加锁，这就是串行化
如何实现读写的多版本并发控制
- 在执行写操作时，使用的是当前读，访问的是最新的数据版本。
- 在执行读操作时，使用的是快照读，访问的是历史的数据版本。’
7.6 Read View 读视图
- 可用 Read View 保证不同的事务，能够看到不同的内容，即隔离级别的实现。
- Read View 就是事务在进行快照读的时候产生的读视图，在改事务执行快照读的那一刻，会生成数据库系统当前的一个快照，用来记录并维护系统当前活跃事务的 ID。
- 当一个事务被开启时，都会被分配一个 ID，这个 ID 是递增的，索引越新的事务，ID 值越大。
- Read View 在 MySQL 的源码中它就是一个类，本质是用来做可见性判断的，当事务对某个记录执行快照读时，会对改记录创建与一个 Read View 读视图，根据这个读视图来判断当前事务能够看到该记录的是哪个版本的数据。
class ReadView { // 省略...... private: // 高水位事务 ID: 大于等于这个 ID 的事务均不可见 trx_id_t m_low_limit_id; // 低水位事务 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 // 存储目前已经出现过的对最大事务 ID 值 + 1 后的值 m_creator_trx_id // 创建该 Read View 的事务的 ID };由于事务 ID 是递增的，因此根据 Read View 中的 m_up_limit_id 和 m_low_limit_id，可将事务 ID 分成三个部分：
- 事务 ID < m_up_limit_id 的事务：一定是生成读视图时已经提交的事务。
- 事务 ID >= m_low_limit_id 的事务：一定时生成读视图时还没开启的事务。
- m_up_limit_id < 事务 ID < m_low_limit_id 的事务： 在生成读视图时可能处于活跃 / 已提交状态的事务，此时需要判断事务 ID 是否存在于 m_ids 中来判断该事务是否已经提交。
read view 是事务可见性的一个类，不是事务创建出来，就会有read view，而是当这个事务（已经存在），首次进行快照读的时候，MySQL形成read view！
8. RC 和 RR 的本质区别
8.1当前读和快照读在RR级别下的区别
启动两个会话客户端，并将各自的会话隔离级别都设置成可重复读 (RR)。（rr read view只有一个）
1. 让两个客户端各自 begin 一个事务，在左事务操作前，先让右事务查看一下表中的 account 表中的数据。
然后我们让左边客户端对表做修改，然后提交，右边还是看不到。
让右客户端的事务使用如下指令以加锁共享的方式执行当前读，能看到被修改后的数据。
2. 这次我们和上面不同，两边同时开启事务后，右边不进行读操作，其它操作都不变。
- 这次，我们发现，直接就能看到左边客户端修改的表数据了。
结论：
- 这两种情况唯一区别在于，右事务在左事务修改数据之前是否进行过快照读。
- 当前面没有进行读取的情况下，就不存在历史版本，只能进行当前读。
- 在可重复读的隔离级别下，只要保证事务对数据的第一次读取和最后一次读取能够读取到同样的数据即可。
8.2 RC和RR本质区别
- Read View 形成的时机不同，会影响事务的可见性。
- 在 RR 隔离级别下，事务第一次进行快照读时会创建一个 Read View，将当前系统中活跃的事务记录下来，此后再进行快照读时就会直接使用这个 Read View 进行可见性判断，因此当前事务看不到第一次快照读之后其他事务所作的修改。
- 而在 RC 隔离级别下，事务每次进行快照读时都会创建一个 Read View，然后根据这个 Read View 进行可见性判断，因此每次快照读时都能读取到被提交了的最新的数据。
- RR 级别下快照读只会创建一次 Read View，所以 RR 级别是可重复读的，而RC 级别下每次快照读都会创建新的 Read View，所以 RC 级别是不可重复读的。
- 前读，能够发现刚才读到的数据确实已经是最新的了。
