02 :日志系统：一条SQL更新语句是如何执行的

redolog：是在存储引擎层，是innodb存储引擎独有的，他有固定的大小，循环写入的，空间足够的时候，数据库压力不大的时候，会慢慢刷到磁盘，当空间不够的时候，会将数据刷到磁盘然后覆盖写最新的数据，他就是mysql说的wal技术，关键点就是先写日志，然后再写磁盘，因为他是顺序写入磁盘，后续读取很快。有了redolog之后，及时数据库发生异常重启，之前提交的记录都不会丢失，这个是crash-safe

关于顺序写为什么快后面连接，kafka也是顺序写入磁盘 参考 https://blog.csdn.net/weixin_43179522/article/details/107434116

binlog:
与redolog的区别：
1.它是server层的日志，与存储引擎无关，redolog是innodb独有的
2.redolog是记录在某个数据页做出了什么修改，binlog是记录具体的sql语句，比如 给id加1这种
3.redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

1.执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2.执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3.引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
4.执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
5.执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
这里我给出这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。

为什么MySQL会突然卡顿一下
对于MySQL中，平时执行很快的更新插入操作，突然卡顿一下，其实就是在写内存和日志，可能就是在刷脏页（脏页就是内存中的数据还没刷到磁盘，与磁盘数据不一致）。一般redolog中会有四种情况
（1）redolog写满了，系统会停止更新操作，会将脏页刷到磁盘中
（2）系统的内存不够了，还是需要淘汰一部分脏页给其他使用，这时候脏页也要写到磁盘
（3）MySQL认为系统空闲的时候，合理刷盘
（4）正常关闭的时候，也会将所有的脏页刷到数据库

第一种是“redo log 写满了，要 flush 脏页”，这种情况是 InnoDB 要尽量避免的。因为出现这种情况的时候，整个系统就不能再接受更新了，所有的更新都必须堵住。如果你从监控上看，这时候更新数会跌为 0。第二种是“内存不够用了，要先将脏页写到磁盘”，这种情况其实是常态。InnoDB 用缓冲池（buffer pool）管理内存
所以
1.一个查询要淘汰的脏页个数太多，会导致查询的响应时间明显变长；
2.日志写满，更新全部堵住，写性能跌为 0，这种情况对敏感业务来说，是不能接受的。

InnoDB 的刷盘速度就是要参考这两个因素：一个是脏页比例，一个是 redo log 写盘速度。
MySQL会控制脏页的比例上限，默认75%。根据 innodb_io_capacity写盘速度和脏页上限处理。并且刷子那个也会有连坐机制，一个脏页旁边如果也是脏页，会一起刷掉，这个可以设置，对于固态一般不需要，机械的话效率较低可以考虑。

备注：参考极客时间MySQL45讲做的笔记