理解完这些基本上能解决面试中MySql的事务问题

越努力，越幸运，
本文已收藏在GitHub中 JavaCommunity , 里面有面试分享、源码分析系列文章，欢迎收藏，点赞
https://github.com/Ccww-lx/JavaCommunity

前言

在面试中，基本上都会问到关于数据库的事务问题，如果啥都不会或者只回答到表面的上知识点的话，那面试基本上是没戏了，为了能顺利通过面试，那MySql的事务问题就需要了解，所以就根据网上的资料总结一版Mysql事务的知识点，巩固一下事务的知识。

事务

事务是指逻辑上的一组操作，要么都执行，要么都不执行,

事务的特性（ACID）

• 原子性( Atomicity )：事务是不可分割的工作单元，要么都成功，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。

• 一致性( Consistency )：事务不能破坏数据的完整性和业务的一致性 。例如在银行转账时，不管事务成功还是失败，双方钱的总额不变

• 隔离性( Isolation )：一个事务所操作的数据在提交之前，对其他事务的可见性设定（一般是不可见）

• 持久性( Durability )：事务提交之后，所做的修改就会永久保存，不会因为系统故障导致数据丢失

严格来说，只有同时满足数据库的事务ACID特性才能算一个完整的事务，但现实中实现能够真正满足的完整的事务特性少之又少，但是在实现中也必须尽量达到事务要求的特性。

那么事务ACID特性具体怎么实现的呢？我们来分析看看，首先先看看事务的特性。

---

原子性( Atomicity )

首先我们来看看事务的原子性特性，看看其如何实现的？

原子性( Atomicity )：事务是不可分割的工作单元，要么都成功，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态

原子性( Atomicity )的实现离不开 MySQL的事务日志 undo log 日志类型，当事务需要回滚的时候需要将数据库状态回滚到事务开始前，即需要撤销所有已经成功执行的sql语句。那么 undo log 起了关键性作用：

当事务对数据库进行修改时，InnoDB会生成对应的 undo log ；如果事务执行失败或调用了 rollback ，导致事务需要回滚，便可以利用 undo log 中的信息将数据回滚到修改之前的样子。

那么 undo log 是什么呢？每个数据变更操作是怎么被记录下来的呢？

undo log（ 回滚日志 ）

undo log (回滚日志)：是采用 段( segment ) 的方式来记录的，每个 undo 操作在记录的时候占用一个 undo log segment 。为什么会在数据更改操作的时候，记录了相对应的 undo log 呢？其目的在于：

• 为了保证数据的原子性，记录事务发生之前的一个版本，用于回滚，
• 通过 mvcc + undo log 实现innodb事务可重复读和读取已提交隔离级别。

其中， undo log 分为：

• insert undo log ： insert 操作中产生的 undo log ，
• update undo log ： 对 delete 和 update 操作产生的 undo log

数据更改的 undo log 怎么记录的呢？

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

而 Delete 操作在事务中实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识 Delete_Bit ，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作需要后台 purge 线程去完成。

update 分为两种情况： update 的列是否是主键列。

• 如果不是主键列，在 undo log 中直接反向记录是如何 update 的。即 update 是直接进行的。
• 如果是主键列， update 分两部执行：先删除该行，再插入一行目标行。

与 insert undo log 不同的， update undo log 日志，当事务提交的时候，innodb不会立即删除 undo log ， 会将该事务对应的 undo log 放入到删除列表中，未来通过 purge 线程来删除。

因为后续还可能会用到 undo log ，如隔离级别为 repeatable read 时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除（即 undo log 不能删除）,且 undo log 分配的页可重用减少存储空间和提升性能。

Note： purge线程两个主要作用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。

接着我们来看看事务的隔离性，看看事务有哪些隔离级别，而且事务并发中会产生什么问题。

---

隔离性( Isolation )

隔离性( Isolation )，是指事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰 ，一个事务所操作的数据在提交之前，对其他事务的可见性设定(一般是不可见)。

事务隔离级别

而且数据库为了在并发下有效保证读取数据正确性，数据库提供了 四种事务隔离级别 >，分别为：

• 读未提交( 脏读 )：允许读取尚未提交的数据，允许脏读
• 读已提交（ 不可重复读 ）：允许读取事务已经提交的数据
• 可重复读（ 幻读 ）：在同一个事务内的查询结果都是和事务开始时刻查询一致的（ InnoDB默认级别 ）
• 串行化：所有事务逐个依次执行， 每次读都需要获得表级共享锁，读写相互都会阻塞

其中， 不同的隔离级别可能会存在在不同并发问题 >，主要并发问题包括：

• 数据丢失： 两个或多个事务操作相同数据，基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新

• **脏读：**读到了其他事务还未提交的数据，事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

• **不可重复读（重点是修改）：**在一个事务中，先后进行两次相同的读取，由于另一个事务修改了数据，导致前后两次结果的不一致，事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

• 幻读（重点是新增、删除）： 在一个事务中，先后进行两次相同的读取（一般是范围查询），由于另一个事务新增或删除了数据，导致前后两次结果不一致

  

不可重复读和幻读的区别？

不可重复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题，

使用锁机制来实现这两种隔离级别，在可重复读中，相同sql第一次读取到数据后就将这些数据加锁，其它事务无法更新操作这些数据来实现可重复读了隔离。

但这种处理方式却无法锁住insert的数据，因此会出现当事务A先前读取了数据，事务B再 insert 数据提交，结果发现事务A就会发现莫名其妙多了些数据，这就是幻读，不能通过行锁来避免 。

了解了并发问题后，来看看不同的隔离级别可能会存在在不同并发问题：

为了实现事务隔离，延伸出了数据库锁。其中， innodb事务的隔离级别是由锁机制和MVCC（多版本并发控制）来实现的

那我们来先看看锁的原理，怎么使用锁来实现事务隔离的呢？

锁机制

锁机制的基本工作原理，事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁，

MySQL主要分成三种类型（级别）的锁机制：

• 表级锁：最大颗粒度的锁机制，锁定资源争用的概率也会最高 ，并发度最低 ，但开销小，加锁快，不会出现死锁，

• 行级锁：最大颗粒度的锁机制很小， 发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能 ，但 开销大，加锁慢；会出现死锁 ，

• 页级锁： 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

而且不同的存储引擎支持不同的的锁机制，主要分析一下InnoDB锁。

InnoDB锁

InnoDB实现了以下两种类型的行锁

• 共享锁（S锁、行锁）：多个事务对同一数据行可以共享一把锁，只能读不能修改
• 排它锁（X锁、行锁）：一个事务获取一个数据行的排它锁，那么其他事务将不能再获取该行的锁（共享锁、排它锁）， 允许获取排他锁的事务更新数据

对于 UPDATE , DELETE , INSERT 操作， InnoDB会自动给涉及及数据集加排他锁（Ｘ）；对于普通SELECT语句，InnoDB不会加任何锁,

而且因为InnoDB引擎允许行锁和表锁共存，实现多粒度锁机制，使用意向锁实现表锁机制，

• 意向共享锁（IS锁、表锁）：当事务准备给 数据行 加共享锁时，会先给 表 加上一个意向共享锁。意向共享锁之间是兼容的
• 意向排它锁（IX锁、表锁）：当事务准备给数据行加排它锁时，会先给表加上一个意向排它锁。意向排它锁之间是兼容的

意向锁(IS、IX)是InnoDB数据操作之前自动加的，不需要用户干预。它的意义在于：当事务想去进行锁表时，可以先判断意向锁是否存在，存在时则可快速返回该表不能启用表锁，否则就需要等待，

其中，四种锁的兼容性如下

如果一个事务请求的锁模式与当前的锁兼容，InnoDB就请求的锁授予该事务；反之，如果两者两者不兼容，该事务就要等待锁释放。

InnoDB行锁

InnoDB的行锁是通过给索引上的 索引项加锁 来实现的。 只有通过索引检索数据，才能使用行锁，否则将使用表锁（锁住索引的所有记录）

临键锁(next-key) ，可以防止幻读。根据索引，划分为一个个 左开右闭 的区间。当进行范围查询的时候，若命中索引且能够检索到数据，则锁住记录所在的区间和它的下一个区间,

其实， 临键锁(Next-Key) = 记录锁(Record Locks) + 间隙锁(Gap Locks) ，

• 当我们用范围条件检索数据而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合范围条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做间隙(GAP)。
• 当使用唯一索引，且记录存在的精准查询时，使用 Record Locks记录锁

具体的使用体现在哪里呢？如下图所示：

• 范围查询，记录存在
  
• 当记录不存在（不论是等值查询，还是范围查询）时，next-key将退化成 Gap Lock（间隙锁）
  
• 当条件是精准匹配（即为等值查询时）且记录存在时，并且是唯一索引， 临键锁(Next-Key) 退化成 Record Lock（记录锁）
  
• 当条件是精准匹配（即为等值查询时）且记录存在，但不是唯一索引时， 临键锁(Next-Key) 会有精准值的数据会增加 Record Lock（记录锁） 和精准值前后的区间的数据会增加 Gap Lock（间隙锁) 。
  

如何使用锁解决并发问题

利用锁解决脏读、不可重复读、幻读

• X锁解决脏读

• S锁解决不可重复读

• 临键锁解决幻读

Multiversion concurrency control ( MVCC 多版本并发控制)

InnoDB 的 MVCC 是通过在每行记录后面保存两个隐藏的列来实现的， 一个保存了行的事务ID（事务ID就会递增 ） ， 一个保存了行的回滚段的指针 。

每开始一个新的事务，都会自动递增产 生一个新的事务id。事务开始时刻的会把事务id放到当前事务影响的行事务id中，而 DB_ROLL_PTR 表示指向该行回滚段的指针，该行记录上所有版本数据，在undo中都通过链表形式组织，该值实际指向undo中该行的历史记录链表，

在并发访问数据库时，对正在事务中的数据做MVCC多版本的管理，以避免写操作阻塞读操作，并且会通过比较版本解决幻读 。

而且MVCC只在 REPEATABLE READ 和 READ COMMITIED 两个隔离级别下才会工作， 其中，MVCC实现实质就是保存数据在某个时间点的 快照 来实现的。 那哪些操作是快照读？

快照读和当前读

快照读 ，innodb快照读，数据的读取将由 cache(原本数据) + undo(事务修改前的数据) 两部分组成

• 普通的 select ，比如 select * from table where ? ;

当前读 ，SQL读取的数据是最新版本。通过锁机制来保证读取的数据无法通过其他事务进行修改

• UPDATE

• DELETE

• INSERT

• SELECT … LOCK IN SHARE MODE

• SELECT … FOR UPDATE

  其中当前读中，只有 SELECT … LOCK IN SHARE MODE 对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。

那么在RR隔离级别下，MVCC具体是如何操作的。

RR隔离级别下，MVCC具体操作

SELECT操作 ，InnoDB遵循以后两个规则执行：

1. InnoDB只查找版本早于当前事务版本的数据行（即行的事务编号小于或等于当前事务的事务编号） ，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的记录。
2. 行的删除版本要么未定义,读取到事务开始之前状态的版本 >,这可以确保事务读取到的行，在事务开始之前未被删除.只有同时满足的两者的记录，才能返回作为查询结果.

INSERT ： InnoDB为新插入的每一行保存当前事务编号作为行版本号 。

DELETE ： InnoDB为删除的每一行保存当前事务编号作为行删除标识 。

UPDATE ： InnoDB为插入一行新记录，保存当前事务编号作为行版本号，同时保存当前事务编号到原来的行作为行删除标识 >。

保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。

分析完了原子性和隔离性，我们继续看看事务的持久性。

持久性( Durability )

持久性( Durability )：事务提交之后，所做的修改就会永久保存，不会因为系统故障导致数据丢失，

而且其实现的关键在于 redo log ， 在执行SQL时会保存已执行的SQL语句到一个指定的Log文件，当执行 recovery 时重新执行 redo log 记录的SQL操作。

那么 redo log 如何实现的呢？

redo log

当向数据库写入数据时，执行过程会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏），这整一过程称为redo log。redo log 分为：

• Buffer Pool内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；
• 磁盘上的重做日志文件(redo log file)，该部分日志是持久的。

Buffer Pool的使用可以大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据在内存还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

为了确保事务的持久性，在当事务提交时，会调用 fsync 接口对 redo log 进行刷盘, （即 redo log buffer 写日志到磁盘的 redo log file 中 ）,刷新频率由 innodb_flush_log_at_trx_commit 变量来控制的：

• 0 ： 每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据 ；
• 1： 事务每次提交都写入磁盘；
• 2：每秒刷新写入到磁盘中的，但跟0是有区别的。

redo log有更加详细的解读，后续有时间再补上，到现在为止，已经将事务三个特性都理解了，那事务一致性呢？

---

一致性( Consistency )

一致性( Consistency )：事务不能破坏数据的完整性和业务的一致性 ：

• 数据的完整性： 实体完整性、列完整性（如字段的类型、大小、长度要符合要求）、外键约束等

• 业务的一致性：例如在银行转账时，不管事务成功还是失败，双方钱的总额不变。

那是如何保证数据一致性的？

其实数据一致性是通过事务的原子性、持久性和隔离性来保证的

• 原子性：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的；实现主要基于undo log
• 持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于redo log
• 隔离性：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制（包含next-key lock）、MVCC（包括数据的隐藏列、基于undo log的版本链、ReadView）

总结

其中要同时满足ACID特性，这样的事务少之又少。实际中很多例子都只是满足一些特性，比如：

• MySQL的NDB Cluster事务不满足持久性和隔离性；
• InnoDB默认事务隔离级别是可重复读，不满足隔离性；
• Oracle默认的事务隔离级别为READ COMMITTED，不满足隔离性

所以我们只能使用这个四个维度的特性去衡量事务的操作。

谢谢各位点赞，没点赞的点个赞支持支持
最后，微信搜《Ccww技术博客》可观看更多文章