mysql的日志文件

了解个大概吧。

上回说到数据库的备份与恢复，日志文件在其中占有很重要的位置。

但是，我查了下资料，发现想搞懂这个数据库日志其实并不容易。包括网上许多文章，说了许多，但我越看越糊涂。只有一些mysql的日志文件原理介绍，相对好一些。mysql因为应用广泛，使用者众，作为数据库的学习对象，也算有代表性。

一、MySQL的日志文件

MySQL中有七种日志文件，分别是：

重做日志（redo log）
回滚日志（undo log）
二进制日志（binlog）
错误日志（errorlog）
慢查询日志（slow query log）
一般查询日志（general log）
中继日志（relay log）

其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。

二、RedoLog（重做日志）

用于崩溃恢复。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。

现在的数据库，为了提高性能，更改数据时，是先更改内存中的数据，然后等积攒了一定数量的更改记录才一起持久化到磁盘。很明显，这样就会有数据丢失的风险。幸而，数据库秉承修改数据先写日志的原则，数据修改时分别写RedoLog和UndoLog，其中RedoLog记录修改信息，而UndoLog是该修改的逆操作，比如，我们做的操作是INSERT，则UndoLog生成一条DELETE语句。所以说，RedoLog上记录的是物理格式，而UndoLog记录的是逻辑格式。

这个Redo文件其实也是先写到内存，但它持久化的频率比较密。比如当事务提交的时候就会持久化到磁盘。

回到上面提到的问题，当操作数据写到内存，事务提交后数据库出故障，由于RedoLog已经持久化，则数据库就可以根据RedoLog上的信息重放，保证用户的操作数据不丢失。

redolog文件大小是固定的，循环往复地使用。

三、UndoLog（回滚日志）

如前所述，undo log 叫做回滚日志，记录数据被修改前的信息，为了在发生错误时回滚之前的操作。

redo log记录的是物理日志，undo是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。

当执行rollback时，就可以用undo log中的逻辑记录进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取（MVCC，多版本并发控制）。

四、BinLog（二进制日志）

用于主从复制和数据恢复。

【主从复制】
从库生成两个线程,一个I/O线程,一个SQL线程；

从库I/O线程请求主库的binlog，并将得到的binlog写到本地的relay-log(中继日志)文件中；而主库则会生成一个log dump线程，用来给从库I/O线程传binlog；

从库SQL线程读取relay log文件中的日志，并解析成sql语句逐一执行。

【数据恢复】
如果数据库误操作, 可以找到距离误操作最近的时间节点的bin log，重放到临时数据库里，然后选择误删的数据节点，恢复到线上数据库。

binlog 是逻辑日志，记录的是这个语句的原始逻辑，即SQL语句。

binlog通过追加的方式记录日志，当文件尺寸大于给配置值后，后续的日志会记录到新的文件上。

五、各日志写入时机

参考资料：
数据库原理四—MySQL日志