上期根据一条查询语句查询流程分析MySQL的整体架构。同样，本期也使用一条查询SQL语句来做引子。可以肯定的是，查询语句执行的流程更新语句同样也会执行。
因此本期的着重点就不在MySQL架构图上，文章标题也给出了大家重点，就是要了解redolog、binlog。
一、redolog第一步，创建一个表user，主键是id，下面是创建语句。
CREATETABLE`user`(`id`int(11)NOTNULLAUTO_INCREMENT,`name`varchar()NOTNULL,`age`tinyint(4)NOTNULL,`time`int(11)NOTNULL,PRIMARYKEY(`id`))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4
插入一条数据
insertintouser(`name`,`age`,`time`)values("咔咔","25",unix_timestamp(now()))
若要将插入的这条数据的age改为26，则需要执行语句
updateusersetage=26whereid=1;
第一期文章中提到一条查询语句的执行流程，该流程与更新语句相同。这里将那幅图拿过来在熟悉一下。
每个模块的功能可以回到第一期文章去查看。
在MySQL8.0中redolog、binlog日志文件都位于/var/lib/mysql此目录下，如图
文件名为ib_logfile的是重做日志，undo开头的就是回滚日志，对于回滚日志后期进行详细的讨论。
redolog（重做日志）是实现事务持久性必备要素，当一个事务提交后，并非直接修改数据库的数据，而是首先保证在redolog中记录相关的操作。
Innodb存储引擎中的redolog大小是固的，上图显示配置了一组两个文件，每个文件大小默认为48M，使用innodb_log_file_size参数来控制单个文件大小，在MySQL5.6.8以及之后版本都默认为48M。
然后redolog可以记录48M的操作，redolog是一个闭环的循环写。所设定的文件个数和文件大小不再增加。
writepos将记录当前位置，同时向后移动，在ib-log-file-3文件末尾后，然后返回ib-logfilg-0文件开始写。
checkpoint记录的是当前擦除的位置，要使文件循环写入，必须一边擦除。清楚数据的前提是要将记录更新到数据文件。
上面的绿色部分就是可写的部分，假设如果writepos追上了checkpoint，那该怎么办？
你必须理解writepos的推进是因为在执行更新操作，这样就不能再执行更新操作，直到记录更新到数据文件，然后checkpoint进行擦除后才可以继续执行更新操作。
对于innodb_log_file_size的设置也是有一些计算规则的，下面将为你介绍。
若innodb_log_file_size设置太小，将导致redolog文件频繁切换，频繁的触发数据库的检查点（checkpoint），导致记录更新到数据文件的次数增加，从而影响IO性能。
同样，如果有一个大的事务，并且所有redolog日志都已写满，但是还没有完成，将导致日志无法切换，从而导致MySQL直接堵死。
innodb_log_file_size设置太大，虽然极大地提高了IO性能，但是在MySQL重启或宕机时，恢复时间会因为redolog文件过大而延长。而这种恢复时间通常是无法控制的。
在设置合理的redolog大小和数量后，Innodb能够保证，即使数据库发生异常重启，以前提交的记录也不会丢失，这一点也称为crash-safe。
在这里，对crash-safe的理解先不提及它是什么，后面的文章会让你明白。
二、如何根据项目情况设置innodb_log_file_size对于参数innodb_log_files_in_group设置3~4个就够用了，不用进行优化。
着重讨论innodb_log_file_size的大小设置或优化设置。
在MySQL8.0之前，通常是计算在一段时间内生成的事务日志(redolog)大小，而MySQL日志文件最小应承载一小时的业务日志量。
此处的一段时间必须视自己的业务情况而定，外界有用1分钟的日志量也有1小时的日志量来计算。
首先看一下MySQL客户端的一个命令pager，在MySQL日常操作中，通过设置pager的显示方式，可以大大提高工作效率。
目前，要查看sequence在一分钟之内的值，您就可以执行pagergrepsequence，它对mysqlshowengineinnodbstatus\Gselectsleep(60);showengineinnodbstatus\G;返回的结果。
禁止pager设置执行nopager，如果不执行该命令，则只有等到下一次重新启动该命令才会失效。
此处咔咔是在虚拟机上做的操作，可以看到一分钟内是没有任何操作，所以值前后相同，你可以在测试服务器做测试。
这样计算出来的select(后边数据-前面的数据)//*60asMB_per_hour;值是一个小时后redolog的大小
但是用这种方法计算一定是不合适的，在一分钟内业务繁忙或者业务空闲时间计算出的值都会产生较大误差。
合适的方法是在一天中确定几个时间点，用一个脚本定时执行，然后记录相应的值，再取平均值，计算出的误差将减至最小。
什么是sequece?当每个binlog生成时，该值从1开始，然后递增，每增加一个事务，sequenumber就加上1。
二、binlog您可以从总体上了解到MySQL架构分为两层，一个是server层，另一个是存储引擎层。
server层当然是负责功能方面的，而存储引擎层则负责处理与存储相关的操作。
而且上面提到的redolog是Innodb存储引擎层特有的，其它存储引擎是不具备的，而server层也有自己的日志记录，就是将要聊到的binlog。
redolog和binlog的区别
redolog是Innodb引擎特有的，而binlog是MySQLserver层特有的，所有引擎都可以使用。
redolog是物理日志，它记录的是一条更新操作所做的修改，binlog是逻辑日志，记录的是一条更新语句执行逻辑
redolog是循环写的，并且空间是固定的，比如上面配置4个1GB的redolog文件，binlog是追加写的，这个文件写完了，换下一个文件，不会覆盖以前的日志。这也就是你经常看到只要你有完整的binlog文件就可以给你恢复到你想要的数据。
MySQL为什么会有俩份日志呢？
在没有Innodb存储引擎之前，MySQL默认存储引擎是MyIsam，但MyIsam是没有重启恢复能力的，binlog日志也仅用于归档。
Innodb是另一家公司以插件的形式引入到Mysql，既然binlog没有重启恢复的能力，那么我就使用redolog来实现重启恢复的功能。
这就导致了当你使用Innodb存储引擎时会写俩份日志。
三、什么是两阶段提交对redolog、binlog有了一定的认识后再来看看一条更新语句的执行流程。
updateusersetage=age+1whereid=1;
执行器先到引擎层找到id=1这一行，由于ID是主键，所以会在主键索引树找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器。否则，需要先从磁盘中读入内存，然后再返回。
执行器拿到存储引擎返回id=2结果后，给age加上1，原来是25，现在就是26,在调用引擎接口写入这行新数据。
引擎将这行数据先更新到内存中，同时将这个更新操作记录到redolog中，此时redolog处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
接着执行器生成这个操作的binlog，并把binlog写入磁盘。
执行器调用引擎的提交事务接口，引擎把刚刚写入的redolog改成提交