mysql底层是有三种日志文件：undo、redo、binlog這里我们是以InnoDB存储引擎为例的，为什么要牵扯去存储引擎呢因为undo、redo是属于InnoDB存储引擎的，binlog才是属于mysql server的日志文件

为什么要这三种日志文件呢

这里主要流程我们可以分为如下几步：

1. 将未修改的数据写入undo日志中，作用：便于数据回滚
2. 写入redo日志redo日志则是记录了对哪个数据做了修妀
3. 准备提交事务将redo日志写入磁盘
4. 准备提交事务将binlog日志写入磁盘（binlog日志记录对哪个数据做了修改，修改结果是什么）
5. IO线程随机将 Buffer Pool 缓冲池中的數据刷入磁盘
   为什么一个简单的更新操作在mysql底层会弄的这么复杂呢?这里我们来简单分析一下

-这是我们对数据回滚的依赖

这个很容易理解任何和磁盘有关的操作性能都是极低的所以，所以mysql会引入Buffer Pool首先是更新缓存，非常快最后在空闲的时候通过后台IO随机更新到磁盘。

redo日志記录了修改后的值防止我们数据丢失，假如我们修改了Buffer Pool缓存中的值还没有来得及刷新磁盘中的数据，数据库宕机了那么Buffer Pool缓存中的数據丢失不是让磁盘中这一条数据成了脏数据吗？但是因为有redo日志可以通过redo日志恢复所以是不要紧的。redo在设置中其实是有几种刷盘策略的这里我们可以简单的了解下：

1. 当参数为0时，提交事务不会将redo日志强制刷入磁盘
2. 当参数为1时提交事务成功一定会将redo日志写入磁盘
3. 当参数為2时，提交事务时将redo日志写入os cache缓存中1秒后写入磁盘

这里三个参数建议是设置为1，强制写入磁盘虽然对性能会有影响，但是可以保证数據的不丢失

对于binlog日志其实也是有个参数控制刷盘策略的就是 sync_binlog，默认为0表示不是直接写入磁盘也是先写入os cache缓存中，所以这里建议是吧sync_binlog参數设置为1强制在提交事务的时候写入磁盘

为什么最后会在redo日志中写入commit标记

这里是为了保证binlog和redo日志的一致性，假设redo日志刚刚写入磁盘文件後mysql宕机了不会因为redo日志有数据而binlog没有数据产生数据不一致问题，因为redo日志文件没有最终标记commit所以这次事务是提交失败的