MySQL：初步了解InnoDB存储引擎的架构设计

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

假设我们有一条SQL语句：

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

那这条SQL语句是如何执行的呢？

系统会通过一个数据库连接发送到MySQL上，然后肯定会经过SQL接口、解析器、优化器、执行器几个环节，解析SQL语句、生成执行计划，然后由执行器负责这个计划的执行，调用InnoDB存储引擎的接口去执行。

今天我们就来探索一下这个存储引擎里的架构设计，以及如何基于存储引擎完成一条更新语句的执行

InnoDB的架构设计

InnoDB的重要内存结构：缓存池

InnoDB存储引擎中有一个非常重要的放在内存中的组件，就是缓冲池（Buffer Pool），这里面会缓存很多的数据，以便于以后查询的时候，如果内存缓冲池中有数据，就可以不用去查数据了。

引擎要执行更新语句的时候，比如对“id = 10”这一行数据，会先查询“id=10”这一行数据是否在缓冲池中，如果不在的话，那么就去磁盘里加载到缓冲池中来，然后对这行记录加锁（因为我们更新“id = 10”这行数据的时候，肯定是不允许别人同时更新的，所以必须要对这行记录加锁）

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

接着下一步，假设“id=10”这行数据的name原来是“zhangsan”，现在需要更新为“xxx”，那么我们就必须先把要更新的原来的值“zhangsan”和“id=10”这条信息，写入到undo日志文件中去。

如果我们执行一个更新数据，要是它在一个事务里的话，那么事务提交之前我们是可以对数据进行回滚的，也就是把更新为“xxx”的值回滚到之前的“zhangsan”去。

所以为了考虑到未来可能要回滚数据的需要，先将更新前的值写入到undo日志文件。

更新buffer pool中的缓存数据

当我们要要更新的那行记录从磁盘文件加载到缓冲池，同时对它加锁之后，以及已将将更新前的旧值写入undo日志文件之后，我们就可以正式开始更新这行记录了。更新的时候，先更新缓冲池中的数据，此时这个数据就是脏数据。

这里所谓的更新内存缓冲池里的数据，意思就是把内存里的“id=10”这行数据的name字段修改为“xxx”

那么为什么说此时这行数据就是脏数据了呢？

因为这个时候磁盘上“id=10”这行数据的name字段还是“zhangsan”，但是内存里这行数据已经被修改了，所以就会叫他是脏数据。

redo log buffer： 万一系统宕机，如何避免数据丢失

问题：上面我们已经把内存里的数据进行了修改，但是磁盘上的数据还没有修改。那么如果此时MySQL系统宕机了，必须会导致内存里修改过的数据丢失，怎么办呢？

这个时候，就必须把内存所做的修改写入到一个Redo Log Buffer里去，这也是内存里的一个缓冲区，是用来存放redo日志的。

所谓redo日志，就是记录下你对数据做了什么修改，比如对“id=10这行记录修改了name字段的值为xxx”，这就是一个日志。

这个redo日志其实是用来在MySQL突然宕机的时候，用来恢复你更新过的数据的，但是我们现在还没法直接讲解redo是如何使用的，毕竟现在redo日志还仅仅停留在内存缓冲里

如果还没有提交事务，MySQL宕机了怎么办？

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

但是，到目前为止，其实还没有提交事务。所以此时如果MySQL崩溃，必然导致内存里Buffer Pool中的修改过的数据都丢失，同时你写入Redo Log Buffer中的redo日志也会丢失。

那么此时数据丢失要紧吗？

其实是不要紧的，因为你一条更新语句，没提交事务，就代表他没执行成功，此时MySQL宕机虽然导致内存里的数据都丢失了，但是你会发现，磁盘上的数据依然还停留在原样子。

也就是说，“id=1”的那行数据的name字段的值还是老的值，“zhangsan”，所以此时你的这个事务就是执行失败了，没能成功完成更新，你会收到一个数据库的异常。然后当mysql重启之后，你会发现你的数据并没有任何变化。

所以此时如果mysql宕机，不会有任何的问题。

提交事务的时候将redo日志写入磁盘中

接着我们想要提交一个事务了，此时就会根据一定的策略把redo日志从redo log buffer里刷入到磁盘文件中去。

这个策略是通过innodb_flush_log_at_trx_commit来配置的，他有几个选项。
（1）当这个参数的值为0的时候，那么你提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，此时可能你都提交事务了，结果mysql宕机了，然后此时内存里的数据全部丢失。

相当于你提交事务成功了，但是由于MySQL突然宕机，导致内存中的数据和redo日志都丢失了，

（2）当这个参数的值为1的时候，你提交事务的时候，就必须把redo log从内存刷入到磁盘文件里去，只要事务提交成功，那么redo log就必然在磁盘里了

那么只要提交事务成功之后，redo日志一定在磁盘文件里，此时你肯定会有一条redo日志说了，“我此时对哪个数据做了一个什么修改，比如name字段修改为xxx了”。

那么只要提交事务成功之后，redo日志一定在磁盘文件里，此时你肯定会有一条redo日志说了，“我此时对哪个数据做了一个什么修改，比如name字段修改为xxx了”。

然后哪怕此时buffer pool中更新过的数据还没刷新到磁盘里去，此时内存里的数据是已经更新过的“name=xxx”，然后磁盘上的数据还是没更新过的“name=zhangsan”。

我们看下图，提交事务之后，可能处于的一个状态。

此时如果说提交事务后处于上图的状态，然后mysql系统突然崩溃了，此时会如何？会丢失数据吗？

肯定不会啊，因为虽然内存里的修改成name=xxx的数据会丢失，但是redo日志里已经说了，对某某数据做了修改name=xxx。

所以此时mysql重启之后，他可以根据redo日志去恢复之前做过的修改，我们看下图。

（3）innodb_flush_log_at_trx_commit参数的值是2时，提交事务的时候，把redo日志写入磁盘文件对应的os cache缓存中，而不是直接进入磁盘文件，可能1s后才会把os cache里的数据写入到磁盘文件里去。

这种模式下，你提交事务之后，redo log可能仅仅停留在os cache内存缓存里，没实际进入磁盘文件，万一此时MySQL机器宕机了，那么os cache里的redo log就会丢失，同样会让你感觉提交事务了，结果数据丢了，看下图。

问题：实际生产中，redo日志的三种刷盘策略，应该设置哪种呢？

建议设置为1.也就是提交事务的时候，redo日志必须刷新到磁盘文件里。

这样可以严格保证提交事务之后，数据是绝对不会丢失的，因为有redo日志在磁盘文件里修复你的所有修改、

如果要是选择0的话，可能你提交事务之后，mysql宕机，那么此时redo日志没有刷盘，导致内存里的redo日志丢失，你提交的事务更新的数据就丢失了；

如果要是选择2的话，如果机器宕机，虽然之前提交事务的时候，redo日志进入os cache了，但是还没进入磁盘文件，此时机器宕机还是会导致os cache里的redo日志丢失。

所以对于数据库这样严格的系统而言，一般建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。