02 | 日志系统：一条SQL更新语句是如何执行的
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了02 | 日志系统：一条SQL更新语句是如何执行的，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3882字，纯文字阅读大概需要6分钟。
内容图文
原文链接：https://time.geekbang.org/column/article/68633
目录
比如这一条语句：update T set c=c+1 where ID=2; 假设c原来的值是1。
概述
上一节中查询语句的执行流程，更新语句也同样会走一遍。
执行语句之前先要连接数据库，这是连接器的工作。
将表T上所有缓存结果都清空（这也是一般不建议使用查询缓存的原因）。
接下来分析器会通过词法分析和语法分析知道这是一条更新语句。
优化器决定要使用ID这个索引。
然后，执行器负责具体执行，找到这一行，然后更新。
和查询流程不一样的是，更新流程还设计两个重要的日志模块，redo log(重做日志) binlog(归档日志)。
重要的日志模块：redo log
先写日志再写磁盘，也就是WAL技术（全称：Write-Ahead Logging）.
具体说，当有一条记录需要更新的时候，InnoDB引擎会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里，而这个更新往往是在系统比较闲的时候做。
InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小为1GB，那么总共可以记录4GB的操作，从头开始写，写到末尾就又回到开头循环写，如下图所示：
write pos是当前位置，一边写一边后移。check point是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。
重要的日志模块：binlog
上一节讲过，MySQL从整体来看，其实就有两块，一块是Server层，它主要做的是MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。
上面的redo log是InnoDB引擎特有的日志，而Server层也有自己的日志，称为binlog(归档日志)。
为什么会有两份日志？ 因为最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有crasf-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件的形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统，也就是redo log来实现crash-safe能力。
两种日志有以下三点不同：
1、redo log是InnoDB引擎特有的；binglog是MySQL的Server层实现的，所有引擎都可以使用。
2、redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如"给ID=2这一行的c字段加1"。
3、redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
InnoDB引擎在执行这个简单的update语句时的内部流程：
1、执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则需要先从磁盘读入内存，然后再返回。
2、执行器拿到引擎给的行数据，把这个值加上1，得到新的一行数据，再调用引擎接口写入这行新数据。
3、引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执完了，随时可以提交事务。
4、执行器生成这个操作的binlog，并把binlog写入磁盘。
5、执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成（commit）状态，更新完成。
执行流程如下图，红色的是执行器执行的，黑色的是存储引擎执行的：
上面将redo log的写入拆成了两个步骤：prepare和commit，这就是“两阶段提交”。
两阶段提交
“两阶段提交”主要是为了让两份日志之间的逻辑一致。
由于redo log和binlog是两个独立的逻辑，如果不使用两阶段提交，肯定就是写完一个再写另一个，这样会有什么问题呢？
1、先写redo log 后写binlog。假设在写完redo log后，binlog还没有写，MySQL异常重启了，那么重启后通过crash-safe能力，所以这一行的值就是2。
但是binlog由于没有写，所以就没有记录这个逻辑，因此之后备份日志的时候，存起来的binlog里面没有这个逻辑。
然后就会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，恢复后的临时库与原库值不同。
2、先写binlog后写redo log。如果在写完binlog后异常重启，服务器恢复以后这个事务无效，数据库的值还是1，但是binlog里面已经记录了将1改为2的逻辑。然后如果要用这个binlog来恢复临时库的时候，恢复以后变成2了，与原值不同。
可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
上一篇：01 | 基础架构：一条SQL查询语句是如何执行的（总结）
内容总结
以上是互联网集市为您收集整理的02 | 日志系统：一条SQL更新语句是如何执行的全部内容，希望文章能够帮你解决02 | 日志系统：一条SQL更新语句是如何执行的所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。