MySQL原理简介—2.InnoDB架构原理和执行流程

大纲

1.更新语句在MySQL中是如何执行的

2.重要的内存结构—Buffer Pool缓冲池

3.undo日志文件如何让更新的数据可以回滚

4.更新Buffer Pool缓冲池中的缓存数据

5.Redo Log Buffer如何避免宕机时数据丢失

6.如果还没提交事务时MySQL宕机了怎么办

7.提交事务时将redo日志写入磁盘中

8.redo日志刷盘策略的选择和建议

9.MySQL的redo log和binlog对比

10.提交事务时同时也会写入binlog

11.binlog日志的刷盘策略分析

12.基于binlog的redo log完成事务的提交

13.在redo日志中写入commit标记的意义

14.后台IO线程随机将内存更新后的脏数据刷盘

15.InnoDB存储引擎的架构原理总结

这里主要介绍MySQL的数据缓存机制

1.更新语句在MySQL中是如何执行的

假设有一条如下这样的SQL语句，那么这条语句是如何执行的呢？

update users set name = 'xxx' where id = 1;

首先Java系统会通过一个数据库连接将该SQL语句发送到MySQL上，然后经过SQL接口、查询解析器、查询优化器、执行器环节，在解析出了SQL语句、生成了执行计划后，再由执行器调用InnoDB存储引擎的接口去执行生成的执行计划。

下面介绍InnoDB存储引擎里的架构设计，以及如何基于InnoDB存储引擎完成一条更新语句的执行。

2.重要的内存结构—Buffer Pool缓冲池

InnoDB有一个非常重要、放在内存里的组件，就是缓冲池(Buffer Pool)。缓冲池会缓存很多磁盘文件数据，以便在查询时不用去查磁盘。如下图示：

所以当InnoDB存储引擎要执行更新语句时：比如对"id=1"这一行数据，会先判断"id=1"这一行数据是否在缓冲池里。如果不在，则直接从磁盘里加载到缓冲池里，且对这行记录加独占锁。

3.undo日志文件如何让更新的数据可以回滚

假设"id=1"这行数据的name原来是"zhangsan"，现在要更新为"xxx"。那么InnoDB得先把原值"zhangsan"和"id=1"写入到undo日志文件中。

Java系统在执行一条SQL更新语句时，要是它在一个事务里，那么事务提交前是可以对数据进行回滚的。所以考虑到可能要回滚数据，InnoDB会把更新前的值写入undo日志文件。如下图示：

4.更新Buffer Pool缓冲池中的缓存数据

当InnoDB把要更新的那行记录从磁盘文件加载到了缓冲池，同时对它加完锁，而且还把更新前的旧值写入undo日志文件后，InnoDB就可以正式开始更新这行记录了。

更新的时候，会先更新缓冲池中的记录，此时这个数据就是脏数据了。所谓的更新内存缓冲池里的数据，意思就是把内存里的"id=1"这行数据的name字段修改为"xxx"。

为什么说此时这行数据是脏数据呢？因为这时磁盘上"id=1"这行数据的name字段还是"zhangsan"，但内存里这行数据已经被修改了，所以它是脏数据。

5.Redo Log Buffer如何避免宕机时数据丢失

现在已经把内存里的数据进行了修改，但是磁盘上的数据还没修改。此时万一MySQL所在机器宕机，必然会导致内存里已修改的数据丢失。这该如何处理？

为此必须把对内存所做的修改写入一个Redo Log Buffer里，Redo Log Buffer也是内存里的一个缓冲区，是用来存放redo日志的。

所谓redo日志，就是记录InnoDB要对数据做什么修改。比如对"id=1"这行记录修改name字段的值为"xxx"，就是一条redo日志。

6.如果还没提交事务时MySQL宕机了怎么办

在数据库中，哪怕执行一条SQL语句，其实也可以是一个独立的事务。只有当事务提交后，SQL语句才算执行结束。

所以如果还没提交事务MySQL宕机了，那么必然导致内存里Buffer Pool中修改过的数据都丢失，同时写入Redo Log Buffer中的日志也会丢失。

此时数据丢失其实是不要紧的。因为一条更新语句只要没提交事务，那么就代表还没执行成功。此时MySQL宕机虽然导致内存里的数据丢失，但还没影响磁盘上的数据。

7.提交事务时将redo日志写入磁盘中

如果InnoDB想要提交一个事务，就会根据一定的策略把redo日志从Redo Log Buffer中刷入到磁盘文件里，这个策略是通过如下这个参数来配置的：innodb_flush_log_at_trx_commit。

(1)当innodb_flush_log_at_trx_commit = 0时

那么进行事务提交时，不会把Redo Log Buffer的数据刷入到磁盘文件里。这时即便提交了事务，但如果MySQL宕机了，内存里的数据也会全部丢失而且redo日志里没有数据。

(2)当innodb_flush_log_at_trx_commit = 1时

那么进行事务提交时，会把内存中的redo log刷入到磁盘文件里。只要事务提交成功，那么redo log就必然在磁盘里。哪怕此时Buffer Pool中更新过的数据还没刷新到磁盘，系统崩溃重启后，也可以根据磁盘中的redo log恢复。

(3)当innodb_flush_log_at_trx_commit = 2时

那么进行事务提交时，会把内存中的redo log写入到OS Cache缓存里。OS Cache缓存里的数据可能在1秒后才会被写入到磁盘文件中。

在这种模式下，当InnoDB存储引擎提交事务后，redo log可能还停留在OS Cache缓存里，还没实际进入到磁盘文件。而此时MySQL所在机器宕机了，那么OS Cache里的redo log也会丢失。从而出现即便提交了事务，但是数据还是丢失了的情况。

8.redo日志刷盘策略的选择和建议

通常建议设置innodb_flush_log_at_trx_commit的值为1。也就是提交事务时，redo日志必须同时刷入磁盘文件里。这样可以严格保证提交事务后数据绝对不会丢失。

如果innodb_flush_log_at_trx_commit = 0，那么提交事务后如果MySQL宕机而此时redo日志还没有刷盘，则会导致内存里的redo日志丢失，内存更新好的数据也丢失。

如果innodb_flush_log_at_trx_commit = 2，那么提交事务后虽然redo日志进入了OS Cache，但OS Cache的数据此时还没进入磁盘文件而MySQL机器宕机了，则也会导致OS Cache的redo日志丢失。

所以一般设置redo日志刷盘策略为1，保证事务提交后数据不会丢失。

9.MySQL的redo log和binlog对比

MySQL的redo log，是一种偏向物理性的重做日志。因为其记录的是：对哪个数据页中的哪条记录做了什么修改。而且redo log是属于InnoDB存储引擎特有的日志文件。

MySQL的binlog，是一种偏向于逻辑性的日志，也叫归档日志。类似"对users表中id=1的一行记录做了更新操作，更新后的值是什么"。binlog不是InnoDB存储引擎特有的日志文件，binlog是属于MySQL数据库层面的日志文件。

10.提交事务时同时也会写入binlog

提交事务时，除了会把redo日志写入到磁盘文件中，还会把这次SQL更新对应的binlog日志写入到磁盘文件中。

下图加入了执行器这个组件，它会负责和InnoDB存储引擎进行交互：

步骤1：从磁盘加载数据到Buffer Pool缓存

步骤2：写入undo日志

步骤3：更新Buffer Pool里的数据

步骤4：写入redo日志到Redo Log Buffer

步骤5：redo日志刷入磁盘

步骤6：写入binlog日志

实际上，执行器是非常核心的一个组件。执行器会与存储引擎完成SQL语句在磁盘与内存层面的全部数据更新操作。

下图把一次更新语句的执行，拆分为两个阶段。其中步骤1、2、3、4是执行更新语句的阶段，而步骤5和6是属于提交事务的阶段。

11.binlog日志的刷盘策略分析

binlog日志也有不同的刷盘策略，通过sync_binlog参数可以控制binlog的刷盘策略，默认值是0。

(1)当sync_binlog设置为0时

表示执行器没有直接将binlog写入磁盘文件，而是先将binlog写入OS Cache缓存，与redo log的innodb_flush_log_at_trx_commit的值为2一样。

如果OS Cache里的数据还没写入磁盘文件时，MySQL所在机器宕机，那么binlog日志也会丢失。

(2)当sync_binlog设置为1时

表示在提交事务时，执行器会把binlog直接写入到磁盘文件中。这样在提交事务后即便宕机，binlog也不会丢失。

12.基于binlog的redo log完成事务的提交

当MySQL把binlog写入磁盘后，接着就会完成最终的事务提交。此时会把本次更新对应的binlog文件名称和位置，都写入到redo日志里，同时在redo日志文件里写入一个commit标记。在完成这个事情后，才算是最终完成事务的提交。

13.在redo日志中写入commit标记的意义

写入commit标记是用来保持redo日志与binlog日志一致。也就是说，在提交事务的时候，上图的步骤5、6、7必须都执行完毕，才算是提交了事务。

(1)如果刚完成步骤5时，redo日志刚刷入到磁盘文件，MySQL宕机了

这时因为在redo日志没有最终的事务commit标记，所以此次事务不成功。因为不允许出现这样的情况：redo日志文件里有更新日志，但是binlog日志文件里没有对应的更新日志。否则就会导致数据不一致。

(2)如果在完成步骤6时，binlog日志已写入磁盘，MySQL宕机了

这时因为在redo日志没有最终的事务commit标记，所以此次事务也失败。所以必须要在redo日志写入最终的事务commit标记，才算事务提交成功。这样redo日志有本次更新的日志，binlog日志也有本次更新的日志，从而实现redo日志和binlog日志完全一致。

14.后台IO线程随机将内存更新后的脏数据刷盘

当完成事务提交后，MySQL已把内存中的Buffer Pool缓存数据更新了，同时磁盘里也有redo日志和binlog日志，但磁盘上的数据文件还是旧值。

这时MySQL会有一个后台IO线程，在事务提交后的某个时间，随机把内存Buffer Pool中修改后的脏数据刷回到磁盘上的数据文件里。

当IO线程把Buffer Pool里修改后的脏数据刷回磁盘后，磁盘上的数据才会跟内存里的数据一样，都是修改后的值。

当IO线程把脏数据刷回磁盘之前，即便MySQL宕机也没关系。因为重启后会根据redo日志恢复提交事务时所做的修改到内存里。之后IO线程还是会把修改后的数据刷到磁盘的数据文件里。

15.InnoDB存储引擎的架构原理总结

InnoDB存储引擎会使用Buffer Pool、Redo Log Buffer来缓存数据。InnoDB存储引擎有属于自己的undo日志文件、redo日志文件，MySQL也有属于自己的binlog日志文件。

执行更新时：会修改Buffer Pool里的数据、写undo日志、写Redo Log Buffer。

提交事务时：会把binlog刷入磁盘、在redo日志中写入事务标记，把redo日志刷入磁盘。最后InnoDB后台的IO线程会随机把Buffer Pool的脏数据刷入到磁盘文件。

(1)MySQL宕机重启如何确定是否需要从redo日志恢复数据

MySQL宕机重启，如何确定脏数据在宕机前是否已全部刷写回磁盘文件。

MySQL宕机重启，InnoDB会首先去查看数据页中LSN的数值。LSN就是InnoDB使用的一个版本标记的计数。如果数据页中的LSN异于redo日志的commit标记，那么就去查看redo日志的LSN大小。如果数据页的LSN值大，则说明数据页领先redo日志，不需要恢复，反之则需要从redo日志中恢复。

(2)从redo日志恢复数据时是全量恢复还是指定位置后恢复

redo日志是划归于一个redo日志组的。默认一个redo日志组有两个redo日志文件。写redo日志时是循环写入，写满一个redo日志文件再写另外一个。

在写满切换redo日志文件时，会触发数据库的检查点checkpoint。checkpoint所做的事就是把脏页刷新回磁盘。

当DB重启恢复时只需要恢复checkpoint之后的数据即可。所以redo日志文件大小不宜过大，不然导致恢复时需要更长的时间。redo日志文件大小也不宜过小，不然导致频繁切换触发检测点降低性能。

(3)既然有redo日志来保证崩溃恢复，为什么还要有binlog日志

binlog日志其实就是归档日志，主要用来做数据恢复的。MySQL最开始设计时只有MyISAM引擎只有binlog，不支持InnoDB。此外数据库备份以及hadoop系统数据分析都是binlog来实现的，所以还需要binlog。

(4)redo日志和binlog日志的数据结构是怎样的

redo日志是循环写，会把redo日志分为0,1,2,3四个区间，有两个指针。writepos指针是一边写一边向后移动，checkpoint指针是一边擦除一边向后移动。所以redo日志是不能保存很多记录的，必须持久化到磁盘中。binlog日志是追加写，不会覆盖之前的日志。

(5)binlog日志和redo日志是怎么保持一致性的

binlog日志和redo日志是通过两阶段提交来保持一致性的。否则如果数据库系统发生crash，则通过redo日志恢复的数据库和通过binlog日志恢复出来的临时库不一致。