mysql 第二讲 一条sql更新语句是如何执行的

mysql 第二讲

redolog（InnoDB特有的日志）

• 更新流程还涉及两个重要的日志模块，它们正是我们今天要讨论的主 角:redo log(重做日志)和 binlog(归档日志)。
• MySQL里经常说到的WAL技术，WAL的全称是Write- Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账 本。
• 当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log(粉板)里 面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作 记录更新到磁盘里面。
• InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环 写。

• checkpoint是当前要擦除的位置

binlog（server层的，所有引擎都能用）

1. redolog是InnoDB引擎特有的;binlog是MySQL的Server层实现的，所有引擎都可以使用。
2. redolog是物理日志，记录的是“在某个数据页上做了什么改”;binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。
3. redolog是循环写的，空间固定会用完;binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
   

将redo log的写入拆成了两个步骤:prepare和commit，这就是"两阶段提交"。

为什么？
这是为了让两份日志之间的逻辑一致。
数据恢复：
首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库;
然后，从备份的时间点开始，将备份的binlog依次取出来，重放到误删表之前的那个时刻。
如果不是两阶段，数据恢复就会出问题。
先写redo log后写binlog：这时候binlog里面就没有记录这个语句。由于这个语句的binlog丢失，这 个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
先写binlog后写redo log：由于redo log还没写，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日 志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是 1，与原库的值不同。