这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记

mysql> create table T(ID int primary key,c int);
mysql> update T set c=c+1 where ID=2;

更新操作跟上一章的查询操作流程类似：先连接数据库（连接器），因为是更新语句，所以清除这张表上的所有缓存结果（MySQL8已经取消了“查询缓存”这个鸡肋操作），到分析器的时候分析出来这是一条更新语句，优化器选择ID这个索引，执行器去做

与查询流程不一样的是，更新流程还涉及两个重要的日志模块：redo log（重做日志）和 binlog（归档日志）。

一、redo log

MySQL中的WAL（Write-Ahead Logging）技术即写前日志，它的关键点是先写日志，再写磁盘。保证事务持久性

这里跟redis的AOF就有区别了，AOF属于写后日志，会先写磁盘再写日志，这是因为redis是内存数据库，所以先做存储（直接更新写入内存），然后再持久化到AOF日志文件。

这两者本质上都是想先以性能消耗最低的方式完成记录操作，MySQL是把随机IO优化成顺序IO优先记录；Redis基于内存数据库的先天优势，直接写入内存，然后持久化到AOF。

写后日志可以减少一步语句验证，因为先写数据，证明语句肯定是无误的，可以直接存，但是有数据丢失风险，写前日志则相反

redo log过程就是写前日志，redo log日志也在磁盘上，不过因为日志的磁盘写入是顺序写，减少了寻址的过程，而数据的写入是随机IO，所以会先写日志，再写磁盘数据。

具体来说，当有一条操作更新的时候，InnoDB引擎会先把记录写到redolog里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候将这个操作记录更新到磁盘中。

但redo log是固定大小的，比如可以