名称解释 

假设我们执行update table set xx = 'yy' where id = 1

buffer pool ：用于缓存数据，数据查询或者更新 都先将数据数据加载到buffer pool中，这样下次查询就直接走缓存了，否则如果数据全从磁盘刷入 效率太低。
buffer pool 是mysql的核心组件，对数据的增删改都是在buffer pool上执行的，因为在磁盘上操作效率太低。

1 更新数据的时候 ，先在bfffer pool 缓冲池中查看数据在缓存中是否存在，如果不存在那么将数据从磁盘刷入到bfffer pool 缓冲池中 同时对数据加独占锁

2 执行更改数据的时候 先将原数据刷入到 undo日志中，用于事务回滚时 或者异常宕机且事务未提交的时候，数据可以回滚	

3 更新数据的时候，不是直接更新磁盘中的数据 而是更新缓冲池中的数据，此时缓存池中的数据是脏数据，因为它和磁盘中的数据不一致

4 假设第三步执行之后 服务器宕机，那么数据就丢失了，更新操作失效。mysql 设计了redo日志来解决这个问题，写redo日志前，先将更新写入 redo log buffer，这个buffer 也是一块内存

5 假设在第四步执行完成之后 服务器宕机，数据也会丢失  因为都是内存嘛。
   当我们程序提交事务之后，mysql会将redo log buffer 刷入到 redo 日志文件中，这样就算宕机了 数据也不会丢失了，因为redo 日志记录了更改 。
   在刷redo日志时，有个innodb_flush_log_at_trx_commit参数，为0时 表示不刷入redo日志，1 表示 立即收入日志文件，2表示先刷如os cache中，os 过一秒再刷入 redo磁盘文件，这样是有一秒时间数据风险的。
   实际中都是设置1的  保证数据不错误

  redo 文件是偏向于流水性的东西，属于innodb 特有的，而bin log是归档日志，偏向于逻辑性，类似于对某行数据进行了更改 更改之后的值是多少。bin log属于mysql server自己的日志文件

6 提交事务后 同时也会写bin log日志，写bin log的时候，有个参数 sync_binlog，默认为0 就是先走os cache，然后再落日志文件，为1 则直接走日志。(和前面类似嘛，走os cache 可能会丢失数据，但是性能高)


7  提交事务后会在redo 日志文件写写入bin log 文件位置与commit标记。这里写commit标记的原因是什么？ 就是为了保持redo 日志和bin log一致

这里总结一下  1 2 3 4 是执行更新语句时做的事，5 6 7 是提交事务时做的事。5 6 7 完成了 才算事务提交了成功。保证了事务提交后 数据不丢失。提交前 数据可能丢失(话说回来 提交前就说明不算真正的更改数据嘛)

8 IO线程 会在某个时间里，将buffer  pool里面的新数据刷(脏数据)新到磁盘文件中

最终还有个redo log刷盘的问题。最终提交的数据还是要更新到磁盘中去的嘛，redo日志刷磁盘其实不是直接刷入到磁盘中去的，中间还有个redo log block，这个block是在mysql启动的时候规划好的一块内存。
在block 刷满之后，在某个时机落盘，具体有哪些落盘时机呢？1 mysql关闭时落盘 2 后台线程定时落盘 3 事务提交(并且设置不走os cache) 等