MySQL的InnoDB引擎实现ACID的基本原理

数据库事务

不知道大家去买东西有没有碰到过，明明已经给老板钱了，但是老板由于某些原因忘记了你给过他钱，让你再付一次；又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的重要性。

有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易

事务的基本定义

事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。

简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。

数据库本地事务

数据库保证事务的ACID四个特性

A：原子性(Atomicity)

一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。

事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。

C：一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。

如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。

如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

I：隔离性(Isolation)

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。

由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

打个比方，你买东西这个事情，是不影响其他人的。

D：持久性(Durability)

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。

InnoDB 实现原理

InnoDB 是 MySQL 的一个存储引擎（插件形式引入），大部分人对 MySQL 都比较熟悉，这里简单介绍一下数据库事务实现的一些基本原理。

在本地事务中，服务和资源在事务的包裹下可以看做是一体的，如下图：

我们的本地事务由资源管理器进行管理

 

事务的 ACID 是通过 InnoDB 日志和锁来保证。

事务的隔离性是通过数据库锁的机制实现的，持久性通过 Redo Log（重做日志）来实现，redo恢复提交事务修改的页操作,redo是物理日志,页的物理修改操作.；

原子性和一致性通过 Undo Log （逻辑日志）来实现。redo恢复提交事务修改的页操作, 页的物理修改操作.。Undo Log 的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为 Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了 Rollback 语句，系统可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

和 Undo Log 相反，Redo Log 记录的是新数据的备份（物理日志，实际做了啥操作）。在事务提交前，只要将 Redo Log 持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是 Redo Log 已经持久化。系统可以根据 Redo Log 的内容，将所有数据恢复到最新的状态。对具体实现过程有兴趣的同学可以去自行搜索扩展。

 

隔离性：

InnoDB中的锁的类型（X、S、IX、IS）。

 

解释为什么引入意向锁

行锁的三种算法：Record Lock，Gap Lock，Next-key Lock

一、InnoDB存储引擎中的锁

锁，在现实生活中是为我们想要隐藏于外界所使用的一种工具。在计算机中，是协调多个进程或县城并发访问某一资源的一种机制。在数据库当中，除了传统的计算资源（CPU、RAM、I/O等等）的争用之外，数据也是一种供许多用户共享访问的资源。如何保证数据并发访问的一致性、有效性，是所有数据库必须解决的一个问题，锁的冲突也是影响数据库并发访问性能的一个重要因素。从这一角度来说，锁对于数据库而言就显得尤为重要。

相对于其他的数据库而言，MySQL的锁机制比较简单，最显著的特点就是不同的存储引擎支持不同的锁机制。根据不同的存储引擎，MySQL中锁的特性可以大致归纳如下：

这里锁的对象是事务，用来锁定数据库中的对象，如：表、页、行。并且一般锁的对象仅在事务commit或rollback后进行释放。并且有死锁机制。

下面我们看InnoDB存储引擎中两种标准的行级锁：

共享锁（S Lock），允许事务读一行数据

排它锁（X Lock），允许事务删除或更新一行数据

若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。

上述情况称为锁不兼容。

此外，InnoDB存储引擎还支持多粒度锁定，这种锁定允许事务在行级上的锁和表级上的锁同时存在。为了支持在不同粒度上进行加锁操作，InnoDB存储引擎支持一种额外的锁方式，称之为意向锁。

所谓意向锁，就是将要锁定的对象分成多个层次，意向锁意味着事务希望在更细粒度上进行加锁。如果把上锁的对象看成树形结构（从根到叶为从粗粒度到细粒度的顺序），那么对最下层的对象上锁，必须先对他的上层节点上锁。

举个例子，比如事务T要对某一行R1加X锁，必须先对R1所在的表T1加意向锁IX（Intention X Lock）。相应的也有IS（Intetion S Lock）锁。

刚开始我也是很懵的，不知道引入意向锁到底是干嘛的。后来再刷书的时候，才豁然开朗。下面我谈下我的理解。

因为引入意向锁是用来实现多粒度锁定的，即行锁和表锁同时存在。我们看看如果不引入意向锁，怎么判断。

如果事务T要对表T1加X锁，那么这是就必须要判断T1表下的每一行记录是否加了S锁或X锁（因为上面提到了锁有不兼容性）。这样做效率无疑很低。那么引入意向锁之后呢？

如果事务T要对表T1加X锁，在这之前，已经有事务对表T1中的行记录R加了S锁，那么此时在表T1上有IS锁，当事务T对表T1准备加X锁时，由于X锁与IS锁不兼容（关于兼容性后面会给出表格），所以事务T要等待行锁操作完成。你看，这样就省去了遍历的操作，提升了锁定父节点（本例为表T1）的效率。

下图就是X、S、IX、IS锁的兼容性了：

二、锁的算法

InnoDB存储引擎有3种行锁的算法，分别是：

Record Lock：单个行记录上的锁

Gap Lock：间隙锁，锁定一个范围，但不包含记录本身

Next-Key Lock：Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身。

举例说明：

假如一个索引有10,11,13,20这四个值。那么该索引可能被Next-Key Locking的区间为：

(-∞，10]

(10,11]

(11,13]

(13,20]

(20,+∞)

注

对于Next_Key Lock，如果我们锁定了一个行，且查询的索引含有唯一属性时（即有唯一索引），那么这个时候InnoDB会将Next_Key Lock优化成Record Lock，也就是锁定当前行，而不是锁定当前行加一个范围；如果我们使用的不是唯一索引锁定一行数据，那么此时InnoDB就会按照本来的规则锁定一个范围和记录。还有需要注意的点是，当唯一索引由多个列组成时，如果查询仅是查找其中的一个列，这时候是不会降级的。还有注意的点是，InnoDB存储引擎还会对辅助索引的下一个键值区间加上gap lock（这么做也是为了防止幻读）。Next_Key Lock是为了解决数据库出现幻读的问题。

关于如何加锁详见我的这篇文章：Mysql的一致性非锁定读和一致性锁定读

有关脏读、不可重复读、幻读详见我的这篇文章浅析Mysql的隔离级别及MVCC

InnoDB存储引擎默认的事务隔离级别是RR级别，即可重复读。在该级别下，采用next-key locking的方式加锁。故而可以防止幻读现象。

举例一下，为什么next-key locking 可以解决幻读问题吧：

所谓幻读，就是在同一事务下，连续执行两次同样的SQL语句可能导致不同的结果，第二次的SQL语句可能会返回之前不存在的行。

创建表t:

这时有三行记录，分别是1,2,5。

假设有如下执行序列：

我们分析一下，会话A在时间2查询的结果为5，由于使用了select...for update语句，为（2，+∞）这个范围加了X锁。因此任何对于这个范围的插入都是不被允许的，由于4在这个范围，所以不允许插入，也就避免了幻读。

 

总结

1. redo log(事务日志)保证事务的原子性和持久性(物理日志)；
2. undo log保证事务的一致性，InnoDB的MVCC也是用undo log来实现的(逻辑日志)；
3. redo log中带有有checkPoint，用来高效的恢复数据；
4. 物理日志记录的是修改页的的详情，逻辑日志记录的是操作语句.。物理日志恢复的速度快于逻辑日志。