MySQL事务

MySql事务

事务的四大特性：原子性(A)、一致性©、隔离性(I)、持久性(D)

原子性：一个事务中的所有语句要么同时成功，要么同时失败。

一致性：一致性是指事务执行前后，数据从一个合法性状态变换到另一个合法性状态。这种状态是语义上的而不是语法上的，跟具体的业务有关。

满足预定的约束的状态就叫做合法的状态。通俗一点，这状态是由你自己 来定义的（比如满足现实世界中的约束）。满足这个状态，数据就是一致的，不满足这个状态，数据就 是不一致的！如果事务中的某个操作失败了，系统就会自动撤销当前正在执行的事务，返回到事务操作 之前的状态。

**隔离性：**事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用数据对并发的其他事务是隔离的，并发执行的各个事务之间不能相互干扰。

**持久性：**持久性是指一个事务一旦提交，它对数据库中数据的改变是永久性的，接下来的其他操作和数据库障碍不应该对其有任何影响。

持久性是通过事务日志来保证的。日志包括了 重做日志 和 回滚日志 。当我们通过事务对数据进行修改 的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做 的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执 行，从而使事务具有持久性。

事务的状态

我们现在知道 事务 是一个抽象的概念，它其实对应着一个或多个数据库操作，MySQL根据这些操作所执 行的不同阶段把 事务 大致划分成几个状态：

活动的（active） 事务对应的数据库操作正在执行过程中时，我们就说该事务处在 活动的 状态。

部分提交的（partially committed） 当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并 没有刷新到磁盘 时，我们就说该事务处在 部分提交的 状态。

失败的（failed） 当事务处在 活动的 或者 部分提交的 状态时，可能遇到了某些错误（数据库自身的错误、操作系统 错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在 失 败的 状态。

中止的（aborted）如果事务执行了一部分而变为 失败的 状态，那么就需要把已经修改的事务中的操作还原到事务执 行前的状态。换句话说，就是要撤销失败事务对当前数据库造成的影响。我们把这个撤销的过程称 之为 回滚 。当 回滚 操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该事 务处在了 中止的 状态。

提交的（committed） 当一个处在 部分提交的 状态的事务将修改过的数据都 同步到磁盘 上之后，我们就可以说该事务处 在了 提交的 状态。

如何使用事务

显示事务

步骤①：start transaction 或者 begin 作用是显示开启一个事务。

start transaction语句相较于begin特别之处在于，后边能跟随几个修饰符：

• READ ONLY:标识当前事务是一个只读事务，也就是属于该事务的数据库操作只能读取数据，而不能修改数据。
• READ WRITE:标识当前事务是一个 读写事务 ，也就是属于该事务的数据库操作既可以读取数据， 也可以修改数据。
• WITH CONSISTENT SNAPSHOT ：启动一致性读。

步骤②：一系列事务中的操作(主要是DML，不含DDL)

步骤③：提交事务或终止事务(即回滚事务)

隐式事务

系统中有一个系统变量autocommit：默认情况下是ON

即默认情况下，系统数据操作会自动进行提交。

当然，如果我们想关闭这种自动提交功能，可以使用下边两种方法之一：

• 显式的的使用 START TRANSACTION 或者 BEGIN 语句开启一个事务。这样在本次事务提交或者回 滚前会暂时关闭掉自动提交的功能。
• 把系统变量 autocommit 的值设置为 OFF ，使用set autucommit = ON

隐式提交数据的情况

​ 数据定义语言（Data definition language，缩写为：DDL）

​ 隐式使用或修改mysql数据库中的表

​ 事务控制或关于锁定的语句

① 当我们在一个事务还没提交或者回滚时就又使用 START TRANSACTION 或者 BEGIN 语句开启了 另一个事务时，会 隐式的提交 上一个事务。

② 当前的 autocommit 系统变量的值为 OFF ，我们手动把它调为 ON 时，也会 隐式的提交 前边语 句所属的事务。

③ 使用 LOCK TABLES 、 UNLOCK TABLES 等关于锁定的语句也会 隐式的提交 前边语句所属的事 务。

​ 加载数据的语句

​ 关于MySQL复制的一些语句

​ 其它的一些语句

当我们设置 autocommit=0 时，不论是否采用 START TRANSACTION 或者 BEGIN 的方式来开启事 务，都需要用 COMMIT 进行提交，让事务生效，使用 ROLLBACK 对事务进行回滚。 当我们设置 autocommit=1 时，每条 SQL 语句都会自动进行提交。 不过这时，如果你采用 START TRANSACTION 或者 BEGIN 的方式来显式地开启事务，那么这个事务只有在 COMMIT 时才会生效， 在 ROLLBACK 时才会回滚。

事务的隔离级别

MySQL是一个 客户端／服务器 架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每 个客户端与服务器连接上之后，就可以称为一个会话（ Session ）。每个客户端都可以在自己的会话中 向服务器发出请求语句，一个请求语句可能是某个事务的一部分，也就是对于服务器来说可能同时处理 多个事务。事务有 隔离性 的特性，理论上在某个事务 对某个数据进行访问 时，其他事务应该进行 排 队 ，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样对 性能影响太大 ，我们既想保持 事务的隔离性，又想让服务器在处理访问同一数据的多个事务时 性能尽量高些 ，那就看二者如何权衡取 舍了

数据并发在mysql中存在的问题

1.脏写：一个事务修改了另一个未提交事务修改过的数据，那就意味着发生了脏写。

2.脏读：对于两个事务A，B。A读取了已经被B修改过了但是没有提交的数据，之后若B回滚，那么A读取的内容就是临时且无效的。

**3.不可重复读：**一个事务第一次读取的数据是另一个事务修改之前的数据，第二次读取的数据是修改过之后的数据，两次读取的数据不一致。那就以为着发生了不可重复读。

**4.幻读：**事务A从一个表中读取了一个字段，然后事务B在该表中插入了一些新的行，之后如果事务A再次读取同一个表，就会多出几行。那就意味着发生了幻读。(幻读只发生在插入操作)

四种隔离级别

上面介绍了几种并发事务执行过程中可能遇到的一些问题，这些问题有轻重缓急之分，我们给这些问题 按照严重性来排一下序：

脏写 > 脏读 > 不可重复读 > 幻读

我们愿意舍弃一部分隔离性来换取一部分性能在这里就体现在：设立一些隔离级别，隔离级别越低，并 发问题发生的就越多。 SQL标准 中设立了4个 隔离级别 ：

• READ UNCOMMITTED:读未提交，在该隔离级别，所有的事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复度、幻读。
• READ COMMITTED:读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。可以避免脏读，但不可重复度、幻读问题仍然存在。
• REPEATABLE READ:可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再次读取该数据，读到的还是原来的内容。可以避免脏读、不可重复读。但是幻读问题仍然存在。这是Msql默认的隔离级别
• SERIALIZABLE:可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间。禁止其他事务对该表执行插入、更新和删除操作。所有并发问题都可以避免。但是性能十分低下。能避免脏读、不可重复度、幻读。

如何设置事务的隔离级别

通过下面的语句修改事务的隔离级别：

SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL `隔离级别`; #其中，隔离级别格式： 
> READ UNCOMMITTED 
> READ COMMITTED 
> REPEATABLE READ 
> SERIALIZABLE

或者：

SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = '隔离级别' #其中，隔离级别格式： 
> READ-UNCOMMITTED 
> READ-COMMITTED 
> REPEATABLE-READ 
> SERIALIZABLE

#查看事务的隔离级别
select @@transaction_isolation;

关于设置时使用GLOBAL或SESSION的影响：

• 使用 GLOBAL 关键字（在全局范围影响）：

  SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; #或 SET GLOBAL TRANSACTION_ISOLATION = 'SERIALIZABLE';
  

  则：

  当前已经存在的会话无效

  只对执行完该语句之后产生的会话起作用

• 使用SESSION关键字(在会话范围影响)：

  SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; #或 SET SESSION TRANSACTION_ISOLATION = 'SERIALIZABLE';
  

  则：

  对当前会话的所有后续的事务有效

  如果在事务之间执行，则对后续的事务有效

  该语句可以在已经开启的事务中间执行，但不会影响当前正在执行的事务

小结： 数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性 就越好，但并发性越弱。

Mysql事务日志

事务有4种特性：原子性、一致性、隔离性和持久性。

那么事务的四种特性到底是基于什么机制实现的呢？

• 事务的隔离性由锁机制实现
• 而事务的原子性、一致性和持久性由事务的redo和undo日志来保证
  • REDO LOG称作重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。
  • UNDO LOG称为回滚自如，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。

Redo日志

为什么需要REDO日志？

如果不使用REDO日志文件，我们要保证事务的一致性，那么必须在每次写入内存的同时同步写入到磁盘中，这种暴力的做法存在以下问题：

• 修改量与刷新磁盘工作量严重不成比例

  有时候我们仅仅修改了某个页面中的一个字节，但是我们知道在Innodb中是以页为单位来进行磁盘IO的，也就是说我们在该事务提交时不得不将一个完整的页面从内存中刷新到磁盘，我们又知道一个页面默认是16KB大小，只修改一个字节就要刷新16KB的数据到磁盘上显然是太小题大作了。

• 随机IO刷新较慢

  一个事务可能包含很多语句，即使是一条语句也可能修改许多页面，加入该事务修改的这些页面并不相邻，这就意味着在将某个事务修改的Buffer Pool中的页面刷新到磁盘时，需要进行很多的随机IO，随机IO比顺序IO要慢，尤其对于传统的机械硬盘来说。

InnoDB引擎的事务WAL技术(Write-Ahead-Logging),这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证ACID中的持久性，这就是redo log的作用。

我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系 统崩溃，在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把该事务在内 存中修改过的全部页面刷新到磁盘，只需要把 修改 了哪些东西 记录一下就好。

一旦服务器宕机，事务在内存中还未刷新至磁盘中，那么再服务器重启之后，会根据redo日志更新相对应的数据。

REDO日志的好处、特点

. 好处

• redo日志降低了刷盘频率
• redo日志占用的空间非常小

特点

• redo日志是顺序写入磁盘的
• 事务执行过程中，redo log不断记录

redo log跟bin log的区别，redo log是存储引擎层产生的，而bin log是数据库层产生的。假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务提交，才会一次写入到bin log文件中。

redo的组成

Redo log可以简单分为以下两个部分：

• 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。

参数设置：innodb_log_buffer_size： redo log buffer 大小，默认 16M ，最大值是4096M，最小值为1M。

• 重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

  

redo的整体流程

以一个更新事务为例，redo log 流转过程，如下图所示：

第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝 第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值 第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加 写的方式 第4步：定期将内存中修改的数据刷新到磁盘中。

Write-Ahead Log(预先日志持久化)：在持久化一个数据页之前，先将内存中相应的日志页持久化。

redo log的刷盘策略

redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以 一 定的频率 刷入到真正的redo log file 中。这里的一定频率怎么看待呢？这就是我们要说的刷盘策略。

注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到 文件系统缓存 （page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系 统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同 步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）。

针对这种情况，InnoDB给出 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务 时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：

设置为0 ：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日 志的同步）

设置为1 ：表示每次事务提交时都将进行同步，刷盘操作（ 默认值 ）

设置为2 ：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自 己决定什么时候同步到磁盘文件。

不同刷盘策略演示

写入redo log buffer 过程(了解)

补充概念：Mini-Transaction

一个事务可以包含若干条语句，每一条语句其实是由若干个 mtr 组成，每一个 mtr 又可以包含若干条 redo日志，画个图表示它们的关系就是这样：

redo 日志写入log buffer

每个mtr都会产生一组redo日志，用示意图来描述一下这些mtr产生的日志情况

不同的事务可能是 并发 执行的，所以 T1 、 T2 之间的 mtr 可能是 交替执行 的。

redo log block的结构图

redo log file

1.相关参数设置

innodb_log_group_home_dir ：指定 redo log 文件组所在的路径，默认值为 ./ ，表示在数据库 的数据目录下。MySQL的默认数据目录（ var/lib/mysql ）下默认有两个名为 ib_logfile0 和 ib_logfile1 的文件，log buffer中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志 文件位置还可以修改。

innodb_log_files_in_group：指明redo log file的个数，命名方式如：ib_logfile0，iblogfile1… iblogfilen。默认2个，最大100个

根据业务修改其大小，以便容纳较大的事务。编辑my.cnf文件并重启数据库生效，如下所示

2.日志文件组

总共的redo日志文件大小其实就是： innodb_log_file_size × innodb_log_files_in_group 。 采用循环使用的方式向redo日志文件组里写数据的话，会导致后写入的redo日志覆盖掉前边写的redo日 志？当然！所以InnoDB的设计者提出了checkpoint的概念。

3.checkpoint

如果 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log记录，MySQL 得 停下来，清空一些记录，把 checkpoint 推进一下。

Undo日志

redo log是事务持久性的保证，undo log是事务原子性的保证。在事务中 更新数据 的 前置操作 其实是要 先写入一个 undo log 。

如何理解Undo日志

事务需要保证 原子性 ，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半 会出现一些情况，比如：

情况一：事务执行过程中可能遇到各种错误，比如 服务器本身的错误 ， 操作系统错误 ，甚至是突 然 断电 导致的错误。

情况二：程序员可以在事务执行过程中手动输入 ROLLBACK 语句结束当前事务的执行。

以上情况出现，我们需要把数据改回原先的样子，这个过程称之为 回滚 ，这样就可以造成一个假象：这 个事务看起来什么都没做，所以符合 原子性 要求。

Undo日志的作用

作用1：回滚数据

用户对undo日志可能有误解：undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。undo是逻辑日志，因此知识将数据库逻辑地恢复到原来的样子。所有的修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。

这是因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页中某几条纪律，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。

作用2：MVCC

undo的另一个作用是MVCC，即在Inno存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定记录。

undo的存储结构

回滚段与undo页

InnoDB对undo log的管理采用段的方式，也就是 回滚段（rollback segment） 。每个回滚段记录了 1024 个 undo log segment ，而在每个undo log segment段中进行 undo页 的申请。

在 InnoDB1.1版本之前 （不包括1.1版本），只有一个rollback segment，因此支持同时在线的事务 限制为 1024 。虽然对绝大多数的应用来说都已经够用。

从1.1版本开始InnoDB支持最大 128个rollback segment ，故其支持同时在线的事务限制提高到 了 128*1024 。

回滚段与事务

1. 每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。

2. 当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数 据会被复制到回滚段。

3. 在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够 用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的盘 区或者在回滚段允许的情况下扩展新的盘区来使用。

4. 回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个 undo表空间。

5. 当事务提交时，InnoDB存储引擎会做以下两件事情：

   将undo log放入列表中，以供之后的purge操作

   判断undo log所在的页是否可以重用，若可以分配给下个事务使用

回滚段中的数据分类

1.未提交的回滚数据(uncommitted undo information)

​ 该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。

2.已经提交但未过期的回滚数据(committed undo information)

​ 该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。

3.事务已经提交并过期的数据(expired undo information)

​ 事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，会优先覆盖“事务已经提交并过期的数据”。

事务提交后并不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undo log来得到行记录之前的版本。故事务提交时将undo log 放入一个链表中，是否可以最终删除undo log及undo log所在页由purge线程来判断。

undo的类型

在InnoDB存储引擎中，undo log分为：

insert undo log

insert undo log是指在insert操作中产生的undo log。因为insert操作的记录，只对事务本身可见，对其他事务不可见(这是事务隔离性的要求)，故该undo log可以在事务提交后直接删除。不需要进行purge操作。

update undo log

update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

undo log的声明周期

简要生成过程

一下是undo+redo事务的简化过程。

假设有2个数值，分别为A=1和B=2，然后将A修改为3，B修改为4

• 在1-8步骤的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。
• 如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。
• 若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

只有Buffer Pool的流程：

有了Redo Log和Undo Log之后：

详细生成过程

当我们执行INSERT时：

begin;
INSERT INTO user (name) VALUES ("tom");

当我们执行UPDATE时：

UPDATE user SET id=2 WHERE id=1;

undo log是如何回滚的

以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：

1. 通过undo no=3的日志把id=2的数据删除
2. 通过undo no=2的日志把id=1的数据的deletemark还原成0
3. 通过undo no=1的日志把id=1的数据的name还原成Tom
4. 通过undo no=0的日志把id=1的数据删除

undo log的删除

针对于insert undo log 因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删 除，不需要进行purge操作。

针对于update undo log 该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等 待purge线程进行最后的删除。

undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。

redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程