最详细的MySQL事务解析：ACID的原理及实现

内容导航：

最详细的MySQL事务解析：ACID的原理及实现

数据库老师会问哪些问题？

数据库的事务机制是什么

什么叫mysql事务？

一、最详细的MySQL事务解析：ACID的原理及实现

提到MySQL的事务，我相信对MySQL有了解的同学都能聊上几句，无论是面试求职，还是日常开发，MySQL的事务都跟我们息息相关。

而事务的ACID（即原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）可以说涵盖了事务的全部知识点，所以，我们不仅要知道ACID是什么，还要了解ACID背后的实现，只有这样，无论在日常开发还是面试求职，都能无往而不利。

上一篇 跟面试官侃半小时MySQL事务隔离性，从基本概念深入到实现 主要围绕“隔离性”展开，从基本概念，到隔离性的实现，最后以一个实战案例进行融会贯通。本篇内容将介绍原子性、一致性、持久性相关实现，由于这部分内容可能很多人会相对陌生，因为日常业务开发可能不太会去接触和深究，但是了解完后，你对MySQL会有更深刻的认识。

1.基本概念原子性。

整个事务是不可分割的最小单位，事务中任何一个语句执行失败，所有已经执行成功的语句也要回滚，整个数据库状态要恢复到执行事务前到状态。

一致性。

事务将数据库从一种状态转变为下一种一致的状态。在事务的前后，数据库的完整性约束没有被破坏。（事务的acid不是完全正交的，尤其是一致性，可能跟原子性、隔离性都有一定关系，后面会看到）

持久性。

事务一旦提交，那么就是永久性的，不会因为宕机等故障导致数据丢失（外力影响不保证，比如磁盘损害）。持久性是保证了数据库的高可靠性（High Reliability），而不是高可用性(Hign Availability)。高可用性并不能通过事务来保证。

2.持久性的实现

MySQL的innoDB存储引擎，使用Redo log保证了事务的持久性。

当事务提交时，必须先将事务的所有日志写入日志文件进行持久化，就是我们常说的WAL（write ahead log）机制（这个技术是保障持久性的关键技术，在HBase中也扮演重要角色，有兴趣的同学可以参考我之前关于HBase的文章）。这样才能保证断电或宕机等情况发生后，已提交的事务不会丢失，这个能力称为 crash-safe。

下面深入聊一聊redo log的机制，给大家更深刻的理解。

Redo log包括两部分，重做日志缓冲（redo log buffer）和重做日志文件（redo log file），前者是易失的缓存，后者是持久化的文件。

举一个事务的例子：

步骤1:begin;步骤2:insert into t1 …r步骤3:insert into t2 …步骤4:commit;

这个事务的写入过程实际拆解如下：

innodb缓冲池的概念本文就不展开说明了，以后有机会可以展开说一下。

重点关注在这个事务提交前，将 redo log 的写入拆成了两个步骤，prepare 和 commit，这就是"两阶段提交”。

为什么要采用两阶段提交呢？

实际上，两阶段提交是分布式系统常用的机制。MySQL使用了两阶段提交后，也是为了保证事务的持久性。Redo log 和bingo 有一个共同的数据字段，叫 XID,崩溃恢复的时候，会按顺序扫描 redo log。

假设在写入binlog前系统崩溃，那么数据库恢复后顺序扫描 redo log，碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务，而且binlog也没写入，所以事务就直接回滚了。假设在写入binlog之后，事务提交前数据库崩溃，那么数据库恢复后顺序扫描 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保证数据不丢失。

这个事务要往两个表中插入记录，插入数据的过程中，生成的日志都得先写入redo log buffer ，等到commit的时候，才真正把日志写到 redo log 文件。（当然，这里不绝对，因为redo log buffer可能因为其他原因被迫刷新到redo log）。

而为了确保每次日志都能写入日志文件，在每次将重做日志缓冲 写入 重做日志文件 后，InnoDB存储引擎都需要调用一次fsync操作，确保写入了磁盘。

对于redo log的持久化，可以如下图所示。

1）先写入redo log buffer，在蓝色区域。

2）写入redo log file，但是还没有fsync，这时候是处于黄色的位置，处于系统缓存。

3）调用fsync，真正写入磁盘。

为了控制 redo log 的写入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取值：

设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。

binlog的写入和redo log一样，也是包括bingo cache和bingo file，同样跟上面的三色层次类似（当然，binlog是server层的，不是存储引擎层的），包括log buffer、文件系统page cache、hard disk。

写入page cache 和 fsync到disk 的时机，是由参数 sync_binlog 控制的：

sync_binlog=0 的时候，表示每次提交事务都只 写入文件系统的page cache，不 fsync；sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；sync_binlog=N(N>1) 的时候，表示每次提交事务都写入文件系统的page cache，但累积 N 个事务后才 fsync。（如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志）

通常我们说 MySQL 的“双 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说，一个事务完整提交前，需要等待两次刷盘，一次是 redo log（prepare 阶段），一次是 binlog。

特别需要区分的是，redo log和binlog的不同。这也是经常在面试中可能会问到的两种日志的差异。

注意有这么几点：

产生位置不同。

redo log是innodb的存储引擎产生的，而binlog是数据库的server层实现的。换句话说，如果你使用MySQL，换其他存储引擎，那么可能没有redo log，但是还是会有binlog。

日志记录的内容形式不同。

binlog是一种逻辑日志，记录对应的SQL语句，而redo log记录了物理日志，是针对每个数据页的修改。

日志写入磁盘时间不同。

binlog只有在事务提交后完成一次写入，对于一个事物而言，在binlog中只有一条记录。而redo log在事务进行中不断被写入，而且是并发写入的，不是顺序写入的。

保存方式不同。

redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

3.原子性的实现

Undo log保证了事务的原子性。

在对数据库进行修改时，innoDB引擎除了会产生redo log，还会产生undo log。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败导致事务需要回滚，就利用undo log中的信息将数据回滚到修改之前的样子。

有人认为undo log是redo log的逆过程，其实是不对的。两个日志文件其实都能看作是一种对数据的恢复操作，redo log恢复事务导致的数据页的修改，而undo log能够恢复数据记录到某个特定的版本。

所以redo log是一种物理日志（数据页的修改），而undo log是一种逻辑日志（数据记录）。

undo log还要另外一个重要作用，就是用于mvcc中，进行多版本控制，也就是实现事务隔离性的基础，当用户读取一行记录时，如果这个记录已接被其他事务占用，那么当前事务就可以通过undo读取之前的行版本信息，用来实现非锁定读取，就是“快照读”。

4.一致性的实现

就像一开始在定义的时候介绍的，事务的ACID性质不是完全正交的，尤其是一致性，我们可以认为原子性、持久性和隔离性都是为了实现事务的一致性。

当然，这里的一致性是指数据库层面的事务一致性。

如果说你在应用层面做一个操作，给转账者扣钱，没给接收者加钱，那么这个不一致跟事务的不一致是没有关系的，需要开发人员自己做业务逻辑一致性的保证。

一、数据库老师会问哪些问题？

1.MySQL 主键与索引的联系与区别

主键是为了标识数据库记录唯一性，不允许记录重复，且键值不能为空，主键也是一个特殊索引。

数据表中只允许有一个主键，但是可以有多个索引。

使用主键会数据库会自动创建主索引，也可以在非主键上创建索引，方便查询效率。

索引可以提高查询速度，它就相当于字典的目录，可以通过它很快查询到想要的结果，而不需要进行全表扫描。

主键索引外索引的值可以为空。

主键也可以由多个字段组成，组成复合主键，同时主键肯定也是唯一索引。

唯一索引则表示该索引值唯一，可以由一个或几个字段组成，一个表可以有多个唯一索引。

2.数据库索引是怎么回事？用的啥数据结构 为什么B+树比B树更合适

一个索引是存储的表中一个特定列的值数据结构（最常见的是B-Tree）。索引是在表的列上创建。所以，要记住的关键点是索引包含一个表中列的值，并且这些值存储在一个数据结构中。请记住记住这一点：索引是一种数据结构 。

什么样的数据结构可以作为索引？

B-Tree 是最常用的用于索引的数据结构。因为它们是时间复杂度低， 查找、删除、插入操作都可以可以在对数时间内完成。另外一个重要原因存储在B-Tree中的数据是有序的。数据库管理系统（RDBMS）通常决定索引应该用哪些数据结构。但是，在某些情况下，你在创建索引时可以指定索引要使用的数据结构。

当我们利用索引查询的时候，不可能把整个索引全部加载到内存，只能逐一加载每个磁盘页，磁盘页对应索引树的节点。那么Mysql衡量查询效率的标准就是磁盘IO次数。如果我们利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的。

那么为了提高查询效率，就需要减少磁盘IO数。为了减少磁盘IO的次数，就需要尽量降低树的高度，需要把原来“瘦高”的树结构变的“矮胖”，树的每层的分叉越多越好，因此B树正好符合我们的要求，这也是B-树的特征之一。

B树 B树的节点为关键字和相应的数据（索引等）

B+树 B+树是B树的一个变形，非叶子节点只保存索引，不保存实际的数据，数据都保存在叶子节点中，B+树的叶子节点为链表，链表放数据，非叶子节点是索引。

对比：

• B树和B+树同样适用于高度越低，查询越快。

• B树查找节点，B+树只需要查询所有节点（索引），B树查询索引和数据。虽然可能第一个就找到，但在极端情况下，需要全查询索引和数据，不如B+树稳定。

• B+树和B树比，B+树的硬盘空间更少，io的读写代价更低。因为B+树节点只有索引，占位更少。在查询的情况下硬盘指针移动更低

哈希表索引是怎么工作的？

哈希表是另外一种你可能看到用作索引的数据结构-这些索引通常被称为哈希索引。使用哈希索引的原因是，在寻找值时哈希表效率极高。所以，如果使用哈希索引，对于比较字符串是否相等的查询能够极快的检索出的值。例如之前我们讨论过的这个查询(SELECT * FROM Employee WHERE Employee_Name = ‘Jesus’) 就可以受益于创建在Employee_Name 列上的哈希索引。哈系索引的工作方式是将列的值作为索引的键值（key），和键值相对应实际的值（value）是指向该表中相应行的指针。因为哈希表基本上可以看作是关联数组，一个典型的数据项就像“Jesus => 0x28939″，而0x28939是对内存中表中包含Jesus这一行的引用。在哈系索引的中查询一个像“Jesus”这样的值，并得到对应行的在内存中的引用，明显要比扫描全表获得值为“Jesus”的行的方式快很多。

哈希索引的缺点

哈希表是无顺的数据结构，对于很多类型的查询语句哈希索引都无能为力。举例来说，假如你想要找出所有小于40岁的员工。你怎么使用使用哈希索引进行查询？这不可行，因为哈希表只适合查询键值对-也就是说查询相等的查询（例：like “WHERE name = ‘Jesus’）。哈希表的键值映射也暗示其键的存储是无序的。这就是为什么哈希索引通常不是数据库索引的默认数据结构-因为在作为索引的数据结构时，其不像B-Tree那么灵活

3.创建索引的注意事项

索引可以提高数据的访问速度，但同时也增加了插入、更新和删除操作的处理时间，解决此问题就是分析应用程序的业务处理、数据使用，为经常被用作查询条件、或者被要求排序的字段建立索引。索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。

创建规则：

• 表的主键、外键必须有索引；

• 数据量超过300的表应该有索引；

• 经常与其他表进行连接的表，在连接字段上应该建立索引；

• 经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

• 索引应该建在选择性高的字段上；

• 索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

• 复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替

• 频繁进行数据操作的表，不要建立太多的索引；

• 删除无用的索引，避免对执行计划造成负面影响；

创建索引需要注意的地方：

• 限制表上的索引数目。对一个存在大量更新操作的表，所建索引的数目一般不要超过3个，最多不要超过5个。索引虽说提高了访问速度，但太多索引会影响数据的更新操作。

• 避免在取值朝一个方向增长的字段（例如：日期类型的字段）上，建立索引；对复合索引，避免将这种类型的字段放置在最前面

• 对复合索引，按照字段在查询条件中出现的频度建立索引

• 删除不再使用，或者很少被使用的索引。

4.MYSQL事务特性和实现原理

ACID表示原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。一个很好的事务处理系统，必须具备这些标准特性：

原子性（atomicity）

一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性

是利用Innodb的undo log。undo log名为回滚日志，是实现原子性的关键，当事务回滚时能够撤销所有已经成功执行的sql语句，他需要记录你要回滚的相应日志信息。

一致性（consistency）

数据库总是从一个一致性的状态转换到另一个一致性的状态。（在前面的例子中，一致性确保了，即使在执行第三、四条语句之间时系统崩溃，支票账户中也不会损失200美元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中。）

数据库通过原子性、隔离性、持久性来保证一致性

隔离性（isolation）

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。（在前面的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外的一个账户汇总程序开始运行，则其看到支票帐户的余额并没有被减去200美元。）

利用的是锁和MVCC机制。MVCC,即多版本并发控制(Multi Version Concurrency Control),一个行记录数据有多个版本对快照数据，这些快照数据在undo log中。如果一个事务读取的行正在做DELELE或者UPDATE操作，读取操作不会等行上的锁释放，而是读取该行的快照版本。

持久性（durability）

一旦事务提交，则其所做的修改会永久保存到数据库。（此时即使系统崩溃，修改的数据也不会丢失。持久性是个有占模糊的概念，因为实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必，而且不可能有能做到100%的持久性保证的策略。）

是利用Innodb的redo log。当做数据修改的时候，不仅在内存中操作，还会在redo log中记录这次操作。当事务提交的时候，会将redo log日志进行刷盘(redo log一部分在内存中，一部分在磁盘上)。当数据库宕机重启的时候，会将redo log中的内容恢复到数据库中，再根据undo log和binlog内容决定回滚数据还是提交数据。redo log体积小，刷盘快。redo log是一直往末尾进行追加，属于顺序IO。效率显然比随机IO来的快

5.redis的原理和优点

redis是一个key-value存储系统.和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希类型）

这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的.

在此基础上，redis支持各种不同方式的排序.与memcached一样，为了保证效率，数据都是缓存在内存中.区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步.

Redis的优点:

• 性能极高 – Redis能支持超过 100K+ 每秒的读写频率。

• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

• 原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。

• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

6.Mysql中的锁机制

Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁

MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

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

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度 来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有 并发查询的应用，如一些在线事务处理（OLTP）系统。

7.ABC联合索引生效问题

对于复合索引：Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。

对于复合索引：Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。

二、数据库的事务机制是什么

回答的有点多请耐心看完。
希望能帮助你还请及时采纳谢谢
1事务的原理
事务就是将一组SQL语句放在同一批次内去执行，如果一个SQL语句出错,则该批次内的所有SQL都将被取消执行。MySQL事务处理只支持InnoDB和BDB数据表类型。

1事务的ACID原则
** 1（Atomicity）原子性**： 事务是最小的执行单位，不允许分割。原子性确保动作要么全部完成，要么完全不起作用；
2（Consistency）一致性： 执行事务前后，数据保持一致；
3（Isolation）隔离性： 并发访问数据库时，一个事务不被其他事务所干扰。
4（Durability）持久性: 一个事务被提交之后。对数据库中数据的改变是持久的，即使数据库发生故障。

1缓冲池（Buffer Pool）
Buffer Pool中包含了磁盘中部分数据页的映射。当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。

2日志缓冲区（Log Buffer）
当在MySQL中对InnoDB表进行更改时，这些更改命令首先存储在InnoDB日志缓冲区（Log Buffer）的内存中，然后写入通常称为重做日志（redo logs）的InnoDB日志文件中。

3双写机制缓存（DoubleWrite Buffer）
Doublewrite Buffer是共享表空间的物理文件的 buffer,其大小是2MB.是一个一分为二的2MB空间。
刷脏操作开始之时,先进行脏页**‘备份’**操作.将脏页数据写入 Doublewrite Buffer.
将Doublewrite Buffer(顺序IO)写入磁盘文件中(共享表空间) 进行刷脏操作.

4回滚日志(Undo Log)
Undo Log记录的是逻辑日志.记录的是事务过程中每条数据的变化版本和情况.
在Innodb 磁盘架构中Undo Log 默认是共享表空间的物理文件的Buffer.
在事务异常中断,或者主动(Rollback)回滚的过程中 ,Innodb基于 Undo Log进行数据撤销回滚,保证数据回归至事务开始状态.

5重做日志(Redo Log)
Redo Log通常指的是物理日志，记录的是数据页的物理修改.并不记录行记录情况。（也就是只记录要做哪些修改，并不记录修改的完成情况） 当数据库宕机重启的时候，会将重做日志中的内容恢复到数据库中。

1原子性
Innodb事务的原子性保证,包含事务的提交机制和事务的回滚机制.在Innodb引擎中事务的回滚机制是依托 回滚日志(Undo Log) 进行回滚数据，保证数据回归至事务开始状态.

2那么不同的隔离级别，隔离性是如何实现的，为什么不同事物间能够互不干扰？ 答案是 锁 和 MVCC。
3持久性
基于事务的提交机制流程有可能出现三种场景.
1 数据刷脏正常.一切正常提交，Redo Log 循环记录.数据成功落盘.持久性得以保证

2数据刷脏的过程中出现的系统意外导致页断裂现象 (部分刷脏成功)，针对页断裂情况,采用Double write机制进行保证页断裂数据的恢复.

3数据未出现页断裂现象,也没有刷脏成功，MySQL通过Redo Log 进行数据的持久化即可

4一致性
从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性

2事务的隔离级别
Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别

脏读： 指一个事务读取了另外一个事务未提交的数据。
不可重复读： 在一个事务内读取表中的某一行数据，多次读取结果不同
虚读(幻读)： 是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。

2基本语法
-- 使用set语句来改变自动提交模式
SET autocommit = 0;
SET autocommit = 1;

-- 注意:
--- 1.MySQL中默认是自动提交
--- 2.使用事务时应先关闭自动提交

-- 开始一个事务,标记事务的起始点
START TRANSACTION

-- 提交一个事务给数据库
COMMIT

-- 将事务回滚,数据回到本次事务的初始状态
ROLLBACK

-- 还原MySQL数据库的自动提交
SET autocommit =1;

-- 保存点
SAVEPOINT 保存点名称 -- 设置一个事务保存点
ROLLBACK TO SAVEPOINT 保存点名称 -- 回滚到保存点
RELEASE SAVEPOINT 保存点名称 -- 删除保存点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


CREATE DATABASE `shop`CHARACTER SET utf8 COLLATE utf8_general_ci;
USE `shop`;

CREATE TABLE `account` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`name` VARCHAR(32) NOT NULL,
`cash` DECIMAL(9,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8

INSERT INTO account (`name`,`cash`)
VALUES('A',2000.00),('B',10000.00)

-- 转账实现
SET autocommit = 0; -- 关闭自动提交
START TRANSACTION; -- 开始一个事务,标记事务的起始点
UPDATE account SET cash=cash-500 WHERE `name`='A';
UPDATE account SET cash=cash+500 WHERE `name`='B';
COMMIT; -- 提交事务
# rollback;
SET autocommit = 1; -- 恢复自动提交
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
3事务实现方式-MVCC
1什么是MVCC
MVCC是mysql的的多版本并发控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别为RR（可重复读）和RC（读提交）生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突，极大的增加了系统的并发性能。

2MVCC的实现机制
InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。

在多版本并发控制中，为了保证数据操作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的；对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中；事务提交成功，新的版本号也就更新到了此数据行中。这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题。

3MVCC下的CRUD
SELECT：
　　当隔离级别是REPEATABLE READ时select操作，InnoDB每行数据来保证它符合两个条件：
　　** 1 事务的版本号 大于等于 创建行版本号**
　 ** 2 行数据的删除版本 未定义 或者大于 事务版本号**
　 【行创建版本号 事务版本号 行删除版本号】
　
INSERT：
　　InnoDB为这个新行 记录 当前的系统版本号。
　　
DELETE：
　　InnoDB将当前的系统版本号 设置为 这一行的删除版本号。
　　
UPDATE：
　　InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为 当前的系统版本号。它同时也会将这个版本号 写到 旧行的删除版本里。
————————————————
版权声明：本文为CSDN博主「@Autowire」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：

三、什么叫mysql事务？

1. 普通事务
以 begin / start transaction 开始，commit / rollback 结束的事务。或者是带有保存点 savepoint 的事务。
2. 链式事务
一个事务在提交的时候自动将上下文传给下一个事务，也就是说一个事务的提交和下一个事务的开始是原子性的，下一个事务可以看到上一个事务的处理结果。MySQL 的链式事务靠参数 completion_type 控制，并且回滚和提交的语句后面加上 work 关键词。
3. 嵌套事务
有多个 begin / commit / rollback 这样的事务块的事务，并且有父子关系。子事务的提交完成后不会真的提交，而是等到父事务提交才真正的提交。
4. 自治事务
内部事务的提交不随外部事务的影响，一般用作记录内部事务的异常情况。MySQL 不支持自治事务，但是某些场景可以用 MySQL 的插件式引擎来变相实现。