上一篇文章重点介绍了MYSQL逻辑架构,包括连接器、查询缓存、分析器、优化器、执行器、存储引擎。介绍了一条查询语句在MYSQL中如何执行的，今天重点介绍一条更新语句在MYSQL中执行顺序，以及涉及到的日志系统中两个重要日志模块redolog、binlog。
首先回顾一下上篇文章，逻辑架构图：
更新语句也是需要执行上图的流程，
update USER set name = 'zhangsan' where id = 2;
我们以一条更新语句为例:
- 客户端建立连接后,首先到分析器进行语法解析,判断这是一条更新语句,然后把查询缓存中把所有与USER表相关缓存全部清空
- 优化器根据条件判断是否走索引树,执行器从内存或磁盘中找到对应数据后返回
- 把执行器返回的数据进行更新操作,再调用存储引擎写入内存中
- 存储引擎写入内存同时,写入redolog日志文件中并且此时redolog状态修改为prepare,通知执行器完成事务
- 执行器生成操作binlog日志,并写入磁盘中
- binlog写入成功后,执行器调用存储引擎把redolog状态修改为commit,完成事务
update语句内部执行流程图:
这里重点介绍redolog(重做日志)和binlog(归档日志)
redolog
redolog是innoDB特有的日志,它就像以前读书时候有人没交作业就会把名字记在小黑板上,等最后放学时候再把小黑板上名字誊写老师的小本本上去。MYSQL中redolog就是那块小黑板而binlog就是老师的小本本,这样操作是避免每一次更新操作都先访问磁盘查到相应数据,再写入磁盘,整个IO操作成本很高。
其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写黑板，等不忙的时候再写小本本。
我们知道小黑板不是无限大，也有大小限制，同样redolog也是如此大小固定,当redolog写满之后,MYSQL会先停止继续写,把redolog刷新到磁盘再继续写。假设redolog有四个文件,大小都是1G,如图所示:
write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。
binlog
binlog是MYSQL Server层归档日志,为什么MYSQL会有两种日志呢?
原来MYSQL只有MYISAM引擎,只有归档功能没有crash-safe能力,后面MYSQL以插件形式引入了innoDB使用redolog日志实现crash-safe能力。
redolog和binlog日志对比:
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
之前提到redolog和binlog结合使用,先把redolog状态改为prepare,等binlog写入后再把redolog状态修改commit,这是非常典型的两阶段提交,目的是保证更新语句在执行过程中mysql突然宕机,重启后数据保持一致。
总结：
今天重点介绍了redolog(重做日志),保证crash-safe和binlog(归档日志)记录语句原始逻辑,他们两个一起使用保证了MYSQL宕机恢复数据一致性。
同时建议设置参数innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。
参考资料:
极客时间:mysql实战45讲
