MySQL整体概述
我们使用MySQL的整个流程是： 在应用调用流程：
所以整个数据库的核心是SQL解析器、执行引擎和存储引擎。
InnoDB存储引擎架构设计
更新数据的流程
缓冲池 Buffer Pool 这是InnoDB的重要组件，这里缓存了查询的大量数据，查询语句先查缓冲池，如果不不存在才查询磁盘。 如果不存在的话查询到了，将会放入到buffer pool中
undo log 更新前，旧数据存储在undo log中，以便于回滚。
Redo log
因为数据只在内存更新了，如果这个时候宕机了则更新后的数据将丢失，这如何处理？ 这里还会记录一个redo log的东西，它记录了你对数据做了什么更改。
Redo log文件用来当出现宕机情况下，内存更新的数据还没刷新到磁盘时，用来恢复数据的。当提交事务时将redo log文件同时刷新到磁盘。关于什么时候将redo log文件刷新到磁盘提供了如下策略，通过参数innodb_flush_log_at_trx_commit来配置：
- 为0时，提交事务时，不会把redo log buffer中的刷新到磁盘
- 为1时，提交事务时，必须将redo log buffer刷新到磁盘
- 为2时，提交事务时，将redo log buffer文件写入磁盘对应的os cache缓存中去，不是直接进入磁盘，可能下一秒刷入磁盘也可能不是。
MySQL的binlog
上面的redo log，它偏向的是一种偏向物理性值的重做日志，它记录的类似这样的东西，“对哪个数据页的什么记录，做了什么修改”。 而binlog叫做归档日志，他里面记录的是偏向于逻辑的日志，类似于“对users表的id=100的记录进行了更新操作，更新后的值是什么”。 binlog不是InnoDB引擎特有的日志，是属于mysql server自己的日志文件。
提交事务的时候，同时会写入binlog 上面提到提交事务的时候，会将redo log日志写入磁盘文件中去。同时还会将这次更新对应的binlog日志写入到磁盘文件中。
在上面的图中加入了执行器这个组件，执行器组件负责和InnoDB存储引擎进行交互，包括加载数据到Buffer Pool、写undo日志文件，更新Buffer Pool里面的值，写redo log buffer文件、将redo log文件刷到磁盘、写binlog等操作。
binlog日志刷盘策略
参数是：sync_binlog 默认是0，写入到os cache中，如果这个时候宕机，那么在os cache中的binlog日志将会丢失 如果将其设置为1，那么在每次事务提交时都将强制将binlog写入到磁盘文件中。
基于redo log和binlog完成事务的提交
当将binlog写入磁盘后，接着就完成最终的事务提交，此时会把本次更新对应的binlog文件名称和这次更新的binlog日志在文件里的位置，都写入到redo log日志文件中，同时在redo log日志文件中写入一个commit标记（意义是保持redo log和binlog日志一致）。 完成这件事之后，才算最终完成了事务的提交。
后台IO线程随机将内存更新后的脏数据刷新到磁盘
MySQL有一个后台的IO线程，会在接下来的某个时间将内存的数据更新到磁盘。
总结
InnoDB存储引擎主要包含：buffer pool, undo log、redo log等内存缓存数据。 MySQL server自己还有binlog日志文件。
当执行更新时，每条SQL语句，将修改buffer pool的数据，写undo log、写redo log还有binlog日志文件 然后后台IO线程会刷新内存数据到磁盘。
