首先,我们先来看看一次查询/更新语句流程图
![2be3a3cadd8b0805e9a4c669bee41526.png](https://i-blog.csdnimg.cn/blog_migrate/d8007e4ec43fb1f0ed4c4a683683ec4e.jpeg)
mysql查询/更新流程图
本文会将重点放在执行器存储引擎之间的交互。
mysql不是每次数据更改都立刻写到磁盘,而是会先将修改后的结果暂存在内存中,当一段时间后,再一次性将多个修改写到磁盘上,减少磁盘io成本,同时提高操作速度。
MySQL通过WAL(write-ahead logging)技术保证事务
过程如下图
![0bc9b2c8be02fdff40bc2bea3093aa43.png](https://i-blog.csdnimg.cn/blog_migrate/e45dc7127b56db1c7b13531551bd5f8d.jpeg)
更新流程
redo log记录方式
![f1464d5b9938722912b0c6a08891eb40.png](https://i-blog.csdnimg.cn/blog_migrate/ce877d10d4af933144526606ae9aca0f.jpeg)
redolog记录方式
write pos表示日志当前记录的位置,当ib_logfile_4写满后,会从ib_logfile_1从头开始记录;check point表示将日志记录的修改写进磁盘,完成数据落盘,数据落盘后checkpoint会将日志上的相关记录擦除掉,即write pos->checkpoint之间的部分是redo log空着的部分,用于记录新的记录,checkpoint->write pos之间是redo log待落盘的数据修改记录。关注公众号Java面试那些事儿,回复关键字面试,领取大厂最新面试题。当writepos追上checkpoint时,得先停下记录,先推动checkpoint向前移动,空出位置记录新的日志。
有了redo log,为啥还需要binlog呢?
1、redo log的大小是固定的,日志上的记录修改落盘后,日志会被覆盖掉,无法用于数据回滚/数据恢复等操作。
2、redo log是innodb引擎层实现的,并不是所有引擎都有。
基于以上,binlog必不可少。
1、binlog是server层实现的,意味着所有引擎都可以使用binlog日志
2、binlog通过追加的方式写入的,可通过配置参数max_binlog_size设置每个binlog文件的大小,当文件大小大于给定值后,日志会发生滚动,之后的日志记录到新的文件上。
3、binlog有两种记录模式,statement格式的话是记sql语句, row格式会记录行的内容,记两条,更新前和更新后都有。
binlog和redo log必须保持一致,不允许出现binlog有记录但redolog没有的情况,反之亦然。之前说过在一个事务中,redolog有prepare和commit两种状态,所以,在redolog状态为prepare时记录binlog可保证两日志的记录一致,下图列出各种情况来说明。
![866093af904b4cd805aec5ea9966252f.png](https://i-blog.csdnimg.cn/blog_migrate/8627f562de02fb1b4712747576690fb9.jpeg)
现在我们再来看看整个完整的流程图
![b2077527da60a30a99ebd4d0f4710d47.png](https://i-blog.csdnimg.cn/blog_migrate/ae1e464f1dd600694f56047ce37d0447.jpeg)
更新流程
相关参数设置建议:
1、innodb_flush_log_at_trx_commit:设置为1,表示每次事务的redolog都直接持久化到磁盘(注意是这里指的是redolog日志本身落盘),保证mysql重启后数据不丢失。
2、sync_binlog:设置为1,表示每次事务的binlog都直接持久化到磁盘(注意是这里指的是binlog日志本身落盘),保证mysql重启后binlog记录是完整的。
作者:Mr林_月生