MySQL45讲学习 redo log 和 binlog两阶段提交

一条SQL更新语句是怎么执行的

大体来说MySQL可以分为Server层和存储引擎层，Server层又包括连接器、分析器、优化器、执行器和查询缓存等。涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

redo log（重做日志）

redo log日志是InnoDB引擎中的，redo log作用是记录对数据一些操作。总所周知mysql的数据最终要落库到磁盘中，但是磁盘的IO效率相对内存操作是很慢的。这时候就引入了一个buffer pool，进行操作修改的数据先写入到buffer pool中，然后空闲了再将数据写入到磁盘中。但是如果在buffer pool的数据还没来的及更新到mysql突然宕机了这时候就会导致数据的丢失。redo log就是对这些操作进行记录。

• redo log操作也叫预先日志持久化
• redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环写

binlog（归档日志）

• binlog是Server层的日志所有引擎都可以使用
• binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
• binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。

SQL的更新过程

mysql> update T set c=c+1 where ID=2;

• 首先执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果在buffer pool中存在则返回给执行器；否则需要去磁盘中获取写入到buffer pool中。
• 执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
• 引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
• 执行器生成这个操作的binlog，并把binlog写入磁盘。
• 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完成。

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

为什么要二阶段提交

假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？

• 先写 redo log 后写 binlog：假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启，由于 binlog 没写完就 crash 了，如果用 binlog 来恢复临时库的话，与原库的值不同
• 先写 binlog 后写 redo log：如果 binlog 写完之后 crash，redo log 还没写，崩溃恢复以后这个事务无效，恢复出来的这一行与原库的值不同，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致