Mysql系列二——Mysql日志（从一条更新语句分析Mysql的日志系统）

Mysql的更新语句以及日志

不管是Mysql的查询语句还是更新等语句都是属于普通的Mysql语句，都要走Mysql的基础结构流程，即上文提过的基础架构：

更新语句的大致执行流程为：
（1）Mysql用户使用账户密码通过连接器的验证后，便建立了一条连接。
（2）语句进入分析器阶段，分析器分析语句是一条更新语句。并且，会将缓存关于此条语句的数据失效。
（3）优化器根据语句的where条件（如果存在的话）选择索引。
（4）执行器执行语句，先连接存储引擎查出相关数据集，然后对数据操作，更新回存储引擎。

以上为更新语句的执行流程，Mysql的日志模块包含在执行过程中：

redolog日志模块（InnoDB）

上面提到的第（4）步执行器执行更新操作，如果每次更新都立即写入到磁盘（即每次更新都要进行一次磁盘I/O），那么耗费的时间太长。
在我们平时写程序的时候，当遇到各种I/O操作时，我们一般会选择多线程并发的技术来提高程序运行的速度，即程序不会串行等待I/O。那么Mysql对于I/O操作的优化便是引入日志模块并且选择WAL技术——Write-Ahead Logging。即先写日志，再写磁盘。

具体细节为：
当一条记录需要更新时，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了。之后，InnoDB会在适当的时候（一般是系统空闲的时候），将这个操作记录更新到磁盘里。

redolog文件是一组循环文件（如同一个圆），即rodolog是固定大小的，redolog有两个点，第一个是当前写入操作的点，称为write point，第二个是当前需要更新并且擦除日志的点，称为 check point。

在更新时，
（1）首先InnoDB会将更新记录到日志中，即write point 处，然后更新到内存。
（2）之后再系统空闲时，InnoDB会在系统空闲时，在check point 处将数据更新到磁盘，并且擦除此条日志，那么check point 也会向前移动。
（3）当日志文件满了，即check point追赶上 write point时，InnoDB会先将日志文件更新到磁盘，将check point 向前推进。

redolog保证了假如数据库异常重启了，仍然可以恢复数据。

redolog是InnoDB特有的。

binlog（Server层）

redolog和binlog的异同：
（1）binlog是Server层的日志，即不论你选择哪种存储引擎，binlog都是可以使用的。redolog是InnoDB特有的存储引擎里的日志。
（2）redolog是物理日志，记录具体是哪个数据页做了什么修改，binlog是逻辑日志，记录了原始语句。
（3）redolog是固定大小循环使用的，而binlog没有固定大小，可以一直追加写入。

带有日志概念更新语句的执行流程：
语句： update Student set age=age+1 where id=1;

这里的redolog分为两次提交（同一事务），相当于将两次日志提交放置在同一事务中。在解释这个之前先阐述日志在恢复数据库的功能和步骤：
（1）假设数据库有周期备份的习惯，这里假设一周一备份。
（2）不小心删掉数据库中一些文件。
（3）先将数据库恢复为上一次备份后的数据。
（4）再根据日志文件更新数据。

如果两个日志是分开两次提交，那么当数据库在两次日志中间崩溃时会造成恢复的数据不一致：

（1）先写redolog再写binlog：假如某一次写了redolog之后崩溃了，没有写binlog。前边说过，如果存储引擎崩溃了也可以根据redolog恢复数据。但是binlog没有该条更新语句的记录，当某次删库恢复数据时，binlog由于缺少该条记录，所以会造成数据不一致。
（2）先写binlog再写redolog：假如某一次写了binlog之后崩溃了，没有写redolog。那么因为redolog没有存储，数据库崩溃重启之后并没有此条更新，但是binlog有。所以之后如果再出现删库恢复数据时，根据binlog恢复数据。会执行该条更新语句，与原库数据不同。

所以，保持redolog和binlog一致性是很有必要的。

总结

Mysql有两种日志，一种为binlog，称为归档日志，存储在Server层，用于恢复数据时使用。另一种为redolog，称为重做日志，是InnoDB的特有的日志，用于存储数据时的中间数据，数据在存储至磁盘之前会先存入日志，之后再系统空闲时会根据redolog存入磁盘。