MySQL 笔记整理（2） --日志系统，一条SQL查询语句如何执行

笔记记录自林晓斌（丁奇）老师的《MySQL实战45讲》

2） --日志系统，一条SQL查询语句如何执行

　　MySQL可以恢复到半个月内任意一秒的状态，它的实现和日志系统有关。上一篇中记录了一条查询语句是如何执行的，对于更新语句，这一套流程也是同样会走一遍。与查询流程不一样的是，更新流程还涉及到两个重要的日志模块。redo log(重做日志) 和 binlog(归档日志)。

redo log:

　　这里林老师举了一个很好的例子，摘录如下。

　　《孔乙己》中的酒店掌柜有一个粉板，用来记录客人的赊账记录。如果赊账的人不多，他可以把顾客名和账目写在粉板上。如果赊账的人太多，粉板写不下了，掌柜的还会有一个专门记录赊账的账本。如果有人要赊账或者还账的话，掌柜的一般有两种做法：

　　如果客人太多，掌柜的一定会选择后者，因为前者的操作实在是太麻烦了。要在账本上翻上个几十页再一条条的查找，然后再用算盘计算。相比之下，在粉板上记录下来就简单的多。

　　同样，在MySQL里也会有这个问题。如果每次更新操作都要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本及查找成本都很高。

MySQL中这种类似粉板和账本配合的过程就是WAL技术（Write-Ahead Logging）它的关键点是先写日志，再写磁盘。
当一条记录需要更新时，InnoDB引擎就会先把记录写到redo log里面，并更新内存（粉板）。同时，InnoDB引擎会在适当的时候将他更新到磁盘里（账单）。
redo log的大小是固定。因此如果系统繁忙，redo log很快就会写满。此时就不得不先把一部分记录更新到磁盘里，然后再进行后续的写入。
有了redo log, InnoDB就可以保证记录不会丢失，这个能力称为 crash-safe。（掌柜把记录写入了粉板，没写入账单。晚上掌柜的忘记这件事了(DB异常重启)，一看粉板（redo log）也可以重新写入账单）

binlog:

之前提到过MySQL分为两层，一是Server层，另一个是引擎层。redo log是InnoDB引擎特有的日志，而Server层也有自己的日志，成为binlog（归档日志）
redo log 与 binlog 有三点不同：

两阶段提交：

(图片来源于极客时间林晓斌《MySQL 实战45讲》,如有版权问题请联系我删除)

　　可以看到最后一部分把redo log拆成了两部分，prepare和commit，这就是“两阶段”提交。

　　关于两阶段提交，如果不这样做的话则上述过程会演变成先写完redo log或者先写完binlog，假设在写完一个log，正在写第二个log时发生异常

先写redo log:前面有提到，由于redo log已经写完，仍能将redo log中的数据恢复回来。但由于binlog中没有这个记录，所以当你使用binlog来恢复临时库时，临时库便会少一次逻辑上的更新，即临时库认为没有这次的更新，故与原数据不同。
先写binlog:由于binlog已经写完，恢复临时库时会执行这次的操作，但redo log中并没有相关记录，这个事务无效也无法恢复，与=原数据不同。

另：innodb_flush_log_at_trx_commit这个参数设置为1表示把redo log直接持久化到磁盘，保证mysql异常重启之后数据不丢失。

sync_binlog设置为1时表示binlog持久化到磁盘，保证mysql异常重启后binlog不丢失。

上篇问题答案：

如果表T中没有字段k，而去执行这个语句 select * from T where k = 1，那么会报错“Unknown column ‘k’ in ‘where clause’”。请问这个错误是在哪个阶段报出的？

答案是分析器。笔记中有暗示啦，

分析器：分析器会先做“词法分析”，即从你输入的"select"这个关键字识别出来这是一个查询语句，把你输入的字符串“ID”识别成“列ID”。之后会进行“语法分析”，判断你输入的sql语句是否满足语法规则。

问题：

巴特西