文章目录

事务及其特性
- 一致性
- 原子性
- 隔离性
- 持久性
并发事务控制
- 单版本控制-锁
- 多版本控制-MVCC
实现原理
- 原子性实现原理
- 持久性实现原理
- 隔离性实现原理
- 一致性实现原理
常见面试题
- 为什么InnoDB能够保证原子性A？用的什么方式？
- 为什么InnoDB能够保证持久性？用的什么方式？
- 为什么InnoDB能够保证一致性？用的什么方式？
- 为什么RU级别会发生脏读，而其他的隔离级别能够避免？
- 为什么RC级别不能重复读，而RR级别能够避免？
- 为什么InnoDB的RR级别能够防止幻读？
本文小结

事务及其特性

大家都知道 ACID (原子性、一致性、隔离性和持久性)

一个逻辑工作单元要成为事务，在关系型数据库管理系统中，必须满足 4 个特性

原子性 : 事务的所有操作，要么全部完成，要么全部不完成，不会结束在某个中间环节
一致性 : 事务开始之前和事务结束之后，数据库的完整性限制未被破坏
隔离性 : 数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然
持久性 : 事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持

ACID 及它们之间的关系如下图所示，比如 4 个特性中有 3 个与 WAL 有关系，都需要通过 Redo、Undo 日志来保证等。

一致性

首先来看一致性，一致性其实包括两部分内容，分别是约束一致性和数据一致性。

约束一致性：我们应该很容易想到数据库中创建表结构时所指定的外键、Check、唯一索引等约束。可惜在 MySQL 中，是不支持 Check 的，只支持另外两种，所以约束一致性就非常容易理解了。
数据一致性：是一个综合性的规定，或者说是一个把握全局的规定。因为它是由原子性、持久性、隔离性共同保证的结果，而不是单单依赖于某一种技术。

原子性

原子性就是前面提到的两个“要么”，即要么改了，要么没改。也就是说用户感受不到一个正在改的状态。MySQL 是通过 WAL（Write Ahead Log）技术来实现这种效果的。

原子性和 WAL 到底有什么关系呢？

举例来讲，如果事务提交了，那改了的数据就生效了，如果此时 Buffer Pool 的脏页没有刷盘，如何来保证改了的数据生效呢？就需要使用 Redo 日志恢复出来的数据。而如果事务没有提交，且 Buffer Pool 的脏页被刷盘了，那这个本不应该存在的数据如何消失呢？就需要通过 Undo 来实现了，Undo 又是通过 Redo 来保证的，所以最终原子性的保证还是靠 Redo 的 WAL 机制实现的。

隔离性

所谓隔离性，指的是一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对其他的并发事务是隔离的。锁和多版本控制就符合隔离性。

持久性

所谓持久性，就是指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，接下来的操作或故障不应该对其有任何影响。前面已经讲到，事务的原子性可以保证一个事务要么全执行，要么全不执行的特性，这可以从逻辑上保证用户看不到中间的状态。但持久性是如何保证的呢？一旦事务提交，通过原子性，即便是遇到宕机，也可以从逻辑上将数据找回来后再次写入物理存储空间，这样就从逻辑和物理两个方面保证了数据不会丢失，即保证了数据库的持久性。

并发事务控制

单版本控制-锁

锁用独占的方式来保证在只有一个版本的情况下事务之间相互隔离，所以锁可以理解为单版本控制。

在 MySQL 事务中，锁的实现与隔离级别有关系，在 RR（Repeatable Read）隔离级别下，MySQL 为了解决幻读的问题，以牺牲并行度为代价，通过 Gap 锁来防止数据的写入，而这种锁，因为其并行度不够，冲突很多，经常会引起死锁。

多版本控制-MVCC

多版本控制也叫作 MVCC，是指在数据库中，为了实现高并发的数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务能看到自己应该看到的数据版本。

那个多版本是如何生成的呢？每一次对数据库的修改，都会在 Undo 日志中记录当前修改记录的事务号及修改前数据状态的存储地址（即 ROLL_PTR），以便在必要的时候可以回滚到老的数据版本。例如，一个读事务查询到当前记录，而最新的事务还未提交，根据原子性，读事务看不到最新数据，但可以去回滚段中找到老版本的数据，这样就生成了多个版本。

多版本控制很巧妙地将稀缺资源的独占互斥转换为并发，大大提高了数据库的吞吐量及读写性能。

实现原理

原子性实现原理

每一个写事务，都会修改 Buffer Pool，从而产生相应的 Redo 日志，这些日志信息会被记录到 ib_logfiles 文件中。因为 Redo 日志是遵循 Write Ahead Log 的方式写的，所以事务是顺序被记录的。

在 MySQL 中，任何 Buffer Pool 中的页被刷到磁盘之前，都会先写入到日志文件中，这样做有两方面的保证。

如果 Buffer Pool 中的这个页没有刷成功，此时数据库挂了，那在数据库再次启动之后，可以通过 Redo 日志将其恢复出来，以保证脏页写下去的数据不会丢失，所以必须要保证 Redo 先写。
因为 Buffer Pool 的空间是有限的，要载入新页时，需要从 LRU 链表中淘汰一些页，而这些页必须要刷盘之后，才可以重新使用，那这时的刷盘，就需要保证对应的 LSN 的日志也要提前写到 ib_logfiles 中，如果没有写的话，恰巧这个事务又没有提交，数据库挂了，在数据库启动之后，这个事务就没法回滚了。所以如果不写日志的话，这些数据对应的回滚日志可能就不存在，导致未提交的事务回滚不了，从而不能保证原子性，所以原子性就是通过 WAL 来保证的。

持久性实现原理

如下图所示，一个“提交”动作触发的操作有：binlog 落地、发送 binlog、存储引擎提交、flush_logs， check_point、事务提交标记等。这些都是数据库保证其数据完整性、持久性的手段。

那这些操作如何做到持久性呢？前面讲过，通过原子性可以保证逻辑上的持久性，通过存储引擎的数据刷盘可以保证物理上的持久性。这个过程与前面提到的 Redo 日志、事务状态、数据库恢复、参数 innodb_flush_log_at_trx_commit 有关，还与 binlog 有关。这里多提一句，在数据库恢复时，如果发现某事务的状态为 Prepare，则会在 binlog 中找到对应的事务并将其在数据库中重新执行一遍，来保证数据库的持久性。

隔离性实现原理

InnoDB 支持的隔离性有 4 种，隔离性从低到高分别为：读未提交、读提交、可重复读、可串行化。

读未提交（RU，Read Uncommitted）。它能读到一个事务的中间过程，违背了 ACID 特性，存在脏读的问题，所以基本不会用到，可以忽略。
读提交（RC，Read Committed）。它表示如果其他事务已经提交，那么我们就可以看到，这也是一种最普遍适用的级别。但由于一些历史原因，可能 RC 在生产环境中用的并不多。
可重复读（RR，Repeatable Read），是目前被使用得最多的一种级别。其特点是有 Gap 锁、目前还是默认的级别、在这种级别下会经常发生死锁、低并发等问题。
可串行化，这种实现方式，其实已经并不是多版本了，又回到了单版本的状态，因为它所有的实现都是通过锁来实现的。

说到隔离性的实现方式，我们通常用 Read View 表示一个事务的可见性。前面讲到 RC 级别的事务可见性比较高，它可以看到已提交的事务的所有修改。而 RR 级别的事务，则没有这个功能，一个读事务中，不管其他事务对这些数据做了什么修改，以及是否提交，只要自己不提交，查询的数据结果就不会变。这是如何做到的呢？

随着时间的推移，读提交每一条读操作语句都会获取一次 Read View，每次更新之后，都会获取数据库中最新的事务提交状态，也就可以看到最新提交的事务了，即每条语句执行都会更新其可见性视图。而反观可重复读，这个可见性视图，只有在自己当前事务提交之后，才去更新，所以与其他事务是没有关系的。

在 RR 级别下，长时间未提交的事务会影响数据库的 PURGE 操作，从而影响数据库的性能，所以可以对这样的事务添加一个监控。

可串行化是通过锁来实现的，所以实际上并不是多版本控制，它的特点也很明显：读锁、单版本控制、并发低。

一致性实现原理

一致性可以归纳为数据的完整性。数据的完整性是通过其他三个特性来保证的，包括原子性、隔离性、持久性，而这三个特性，又是通过 Redo/Undo 来保证的，为了保证数据的完整性，提出来三个特性，这三个特性又是由同一个技术来实现的，所以理解 Redo/Undo 才能理解数据库的本质。

如上图所示，逻辑上的一致性，包括唯一索引、外键约束、check 约束，这属于业务逻辑范畴。

常见面试题

为什么InnoDB能够保证原子性A？用的什么方式？

其实这个在上面Undo log中已经提及了。在事务里任何对数据的修改都会写一个Undo log，然后进行数据的修改，如果出现错误或者用户需要回滚的时候可以利用Undo log的备份数据恢复到事务开始之前的状态。

为什么InnoDB能够保证持久性？用的什么方式？

这个在上面Redo log中已经提及了。在一个事务中的每一次SQL操作之后都会写入一个redo log到buffer中，在最后COMMIT的时候，必须先将该事务的所有日志写入到redo log file进行持久化（这里的写入是顺序写的），待事务的COMMIT操作完成才算完成。即使COMMIT后数据库有任何的问题，在下次重启后依然能够通过redo log的checkpoint进行恢复。也就是上面提到的crash recovery。

为什么InnoDB能够保证一致性？用的什么方式？

在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。

首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。

在数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。（上面说过了是用Undo log来保证的）

但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果，比如丢失更新问题。

为了保证并发情况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。

为什么RU级别会发生脏读，而其他的隔离级别能够避免？

RU级别的操作其实就是对事务内的每一条更新语句对应的行记录加上读写锁来操作，而不把一个事务当成一个整体来加锁，所以会导致脏读。但是RC和RR能够通过MVCC来保证记录只有在最后COMMIT后才会让别的事务看到。

为什么RC级别不能重复读，而RR级别能够避免？

这个在上面的MVCC的最后说到了，在RC事务隔离级别下,每次语句执行都关闭ReadView,然后重新创建一份ReadView。而在RR下,事务开始后第一个读操作创建ReadView,一直到事务结束关闭。

为什么InnoDB的RR级别能够防止幻读？

这个是因为RR隔离级别使用了Next-key Lock这么个东东，也就是Gap Lock+Record Lock的方式来进行间隙锁定。

本文小结

本文首先简单介绍了事务的四大特性，分析每个特性的实现原理，以及和四大特性有关的常见面试题。

事务的4大特性及实现原理相关推荐

mysql事务的4大特性
事务的四大特性(简称ACID) 1.原子性(Atomicity) 事务是数据库的逻辑工作单位,事务中包括的诸操作要么全做,要么全不做.2.一致性(Consistency) 事务执行的结果必须是使数据库 ...
数据库事务的4大特性与隔离级别
本篇讲诉数据库中事务的四大特性(ACID),并且将会详细地说明事务的隔离级别. 如果一个数据库声称支持事务的操作,那么该数据库必须要具备以下四个特性: ⑴ 原子性(Atomicity) 原子性是指事务 ...
详述MySQL事务及ACID特性的实现原理
" 事务是 MySQL 等关系型数据库区别于 NoSQL 的重要方面,是保证数据一致性的重要手段. 本文将首先介绍 MySQL 事务相关的基础概念,然后介绍事务的 ACID 特性,并分析其实 ...
ACID特性的实现原理与MySQL事务的关系
深入学习MySQL事务:ACID特性的实现原理事务是MySQL等关系型数据库区别于NoSQL的重要方面,是保证数据一致性的重要手段.本文将首先介绍MySQL事务相关的基础概念,然后介绍事务的ACID ...
MySQL事务特性及实现原理
MySQL事务详解什么是事务简单来说,事务是指逻辑上的一组操作,要么全都执行,要么全部执行失败. 举个栗子:事务最常见的例子就是转账了.假如小红要给小明转1000元,转账会涉及两个关键的步骤: 小 ...
深入学习MySQL事务：ACID特性的实现原理
事务是MySQL等关系型数据库区别于NoSQL的重要方面,是保证数据一致性的重要手段.本文将首先介绍MySQL事务相关的基础概念,然后介绍事务的ACID特性,并分析其实现原理. MySQL博大精深,文 ...
事务的四大特性及实现原理
事务的四大特性及实现原理 1.原子性(Atomicity) 不可再分,事务的最小单位.在一个事务中,我们对数据库的操作,要么都成功,要么都失败,不可能出现部分成功或部分失败的情况.若操作失败必须回滚. ...
Mongodb存储特性与内部原理
前言本文重点叙述下mongodb存储特性和内部原理, 下一篇文章咱们一起来搭建下Replica Sets+Sharded Cluster的集群存储引擎 wiredTiger引擎 1.3.0新增引擎 ...
MySQL事务处理特性的实现原理
摘要:事务这个词来自于英语中的transactional这个词的翻译,这个词的含义更多的是指 "交易".在数据库系统或者软件系统中我们通常称 transactional 为事务 ...

事务的4大特性及实现原理