MySQL 学习笔记（一）MySQL 事务的ACID特性

MySQL事务是什么，它就是一组数据库的操作，是访问数据库的程序单元，事务中可能包含一个或者多个 SQL 语句。这些SQL 语句要么都执行、要么都不执行。我们知道，在MySQL 中，有不同的存储引擎，有的存储引擎比如MyISAM 是不支持事务的，所以说MySQL 事务实际上是发生在 存储引擎部分。

事务主要有四大特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和 持久性（Durability）。它实际上是从四个方面来阐述MySQL 事务的特点，下面就分别来看MySQL 通过什么方式来实现这些特性。

一、原子性#

1. 原子性定义#

原子性就是指事务的不可分割性，对于一个事务而言，就是要么都执行，要么都不执行。在MySQL 中是通过回滚来实现，比如事务中的一个 SQL 语句失败了，那么该事务的所有SQL 语句必须都进行回滚，退回到事务前的状态。

2. InnoDB 中原子性的实现#

上面说到，MySQL 中原子性是通过回滚的方式来实现，那么回滚是怎么实现的？这就涉及到MySQL 中的Undo 日志，原子性就是通过 Undo log 来实现的。

具体是Undo log 会在一个事务中，记录当前 SQL 语句的上一个语句成功的执行状态，如果在执行当前 SQL 语句失败后，就可以通过 Undo log 来回滚到 SQL 语句执行前的状态，这样就能保证事务的原子操作。举个例子，比如插入一条记录：insert into test values(1,'刘备','蜀')实际上得到的记录图如下，中间的 roll_pointer 是指向undo log的指针。

undo log 在事务提交后，undo log 日志也就会被回收。

二、持久性#

1.持久性定义#

持久性是指事务一旦提交，它对事务的改变是永久性的，哪怕系统发生了故障，也不会改变其提交的结果。持久性是通过 Redo log 来实现的。

2.InnoDB 中持久性的实现#

在讲持久性之前，先介绍一下MySQL 中 Buffer pool，我们知道MySQL 数据是存储在磁盘中，为了实现快速读写数据，我们会在内存中设置一个 Buffer pool 缓冲池，数据库可以直接与 Buffer Pool 进行读取交互，定期再将 Buffer Pool 数据存储到磁盘中，这样会大大提高数据库的读写效率。

但是如果系统断电或者宕机，内存是无法保存信息的，而此时刚好Buffer Pool 数据没有同步到磁盘上，就会造成数据丢失。因此就需要 redo log 来对更新和修改操作进行记录，使得在系统重启时能够恢复到原来的状态。

Redo log 是一种预写式日志（write-Ahead Log），它记录的是在某个数据页上做了什么修改。当有记录需要更新时，InnoDB 引擎会先把记录写到 redo log 中，在系统空闲时，再将操作记录更新到磁盘中。redo log 结构如下图所示：

• write pos 是当前记录的位置
• checkpoint 当前要擦除的位置
• write pos 和 check point 之间是 redo 内存区域中还空着的部分，用于记录新的操作。

redo log 只需要记录真正修改的部分，它的同步效率要比 buffer 同步数据快的多。那么 redo log 何时会同步到磁盘中去，主要是 innodb_flush_log_at_trx_commit这个参数的设置：

• 0：表示当提交事务时，并不将缓冲区的 redo log 写入磁盘的日志文件，而是等待主线程每秒刷新
• 1：在事务提交时将缓冲区的 redo log 同步写到磁盘中，保证一定会写入成功
• 2：在事务提交时将缓冲区的redo 日志异步写入到磁盘中，即不能完全保证 commit 时肯定会写入到 redo 日志文件，只是有这个动作。

建议这个参数设置为1 ，同步写入磁盘中。

3.Binlog 和 Redo log#

binlog 和 redo log 日志的区别#

我们知道 redo log 是InnoDB 存储引擎的事务日志，那么对于 server 层是否也存在事务日志，答案是确定的，server 层的事务日志就是 binlog (归档日志)。为啥会出现两种事务日志，是因为最开始的 MySQL 中并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM ,用的就是 binlog 日志来实现事务。那么两者具体有什么区别呢：

• redo log 是InnoDB 引擎特有的，binlog 是 server 层实现，所有的存储引擎都可以使用
• redo log 是物理日志，它存储的是在数据页上的修改；binlog 是逻辑日志，存储的是sql 语句的原始逻辑
• redo log 空间是固定的，会使用完并覆盖原来的日志。binlog 可以追加写入，不会覆盖原来的日志

binlog 和 redo log 日志的两阶段提交#

既然在MySQL 中存在两种日志，那么为了让两份日志之间的逻辑一致，就需要两阶段提交来实现这一任务。具体怎么实现的，我们以这个语句update T set c=c+1 where ID = 2来看:

• 1.执行器先通过执行引擎查找 ID=2 这一行，如果数据在内存Buffer Pool 中直接返回。如果在磁盘中，则先从磁盘中读取到内存中，然后再返回。
• 2.对取到的数据进行操作，将值加1后得到新的数据，再调用引擎写入数据，更新内存。
• 3.同时将对数据页的修改记录到 redo log 中，这个时候 redo log 处于第一个阶段 prepare。
• 4.执行器生成对于这个操作的 binlog ,并将 binlog 写入磁盘中
• 5.执行器调用提交事务接口，把刚刚写入的 redo log 修改成 commit 状态，更新到此完成。

三、隔离性#

1.隔离性定义#

隔离性是指事务内部的操作与其他事务是隔离的，并发过程中的各个事务之间不能互相干扰。对于事务的操作，主要分成两种：读操作与写操作之间的影响、写操作与写操作之间的影响。

2.隔离性的实现#

上面我们说到了事务之间的影响主要分成两个方面，那么MySQL 中是如何处理这两种情况的呢？

• 写操作与写操作：就像 java 中的锁一样，通过锁来解决（MySQL 锁后续会出一篇文章详细介绍）
  • 幻读
• 写操作与读操作：主要是通过 MVCC 机制来解决（MVCC 后续会出一篇文章进行介绍）
  • 脏读
  • 不可重复读

写操作与写操作的隔离实现#

我们可以通过锁的方式，来保证同一时刻的一个数据的写操作只能被一个事务所执行。

在MySQL 中，根据加锁范围，大致可以分成三类：全局锁、表级锁和行级锁。 在一个事务修改数据前，需要获取对应的锁才能修改对应的数据。其他事务想要修改该数据，必须要等到之前的事务提交或回滚释放锁后，才能抢这个锁来修改数据。

锁的概况可以通过以下语句进行查询：

# 锁的概况
select * from information_schema.innodb_locks;
# InnoDB 整体状态，也包括锁的情况
show engine innodb status

写操作与读操作的隔离实现#

为了保证性能，我们不能把所有操作都进行上锁，对于写操作和读操作，可以使用不加锁的方式来实现事务隔离。主要就是通过MySQL 中的 MVCC 机制来解决。

四、一致性#

一致性的定义与实现#

一致性的实现就是在前面三个特性实现的基础上而来的，没有前面三个特性的实现，也就达不到最后数据库事务的一致性。

参考资料#

https://time.geekbang.org/column/article/68963

https://www.cnblogs.com/kismetv/p/10331633.html

网络摘文，版权归原作者。

MySQL 学习笔记（一）MySQL 事务的ACID特性