bin log、redo log、undo log

一、binlog：

binlog简介:mysql的逻辑日志，由mysql server层进行记录。用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。

逻辑日志：记录sql语句。

物理日志：记录数据页变更。

binlog以追加的方式写入，

使用场景：主从复制 和 数据恢复

1.主从复制：主库将变更写入binlog日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay中继日志(relay log)中。从库中有一个SQL线程会从中继日志读取binlog，再执行binlog日志中的内容，即在自己本地再次执行一遍SQL语句，从而使从服务器和主服务器的数据保持一致。

2.数据恢复：通过mysqlbinlog日志管理工具来恢复数据

binlog刷盘时机：Innodb只有在事务提交时才会记录binlog，mysql通过sync_binlog参数控制刷盘时机，其取值范围为0-N:

0：不去强制要求，由系统自行判断何时写入磁盘；

1：每次commit都把binlog写入磁盘；

N:每N个事务，才将binlog写入磁盘。

binlog日志格式：

binlog日志有三种格式，statement、row、mixed。

①statement：基于sql语句复制，每一条修改的sql会记录到binlog

优点：不需要记录每一行的变化，减少binlog日志量，节约io，提升性能

缺点：可能会导致主从不一致，例如执行sysdate()函数

②row：基于行的复制，sql语句的上下文信息，仅需记录哪条数据被修改了。

优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；

缺点：会产生大量的日志，比如一些alter table操作会让日志暴涨

③mixed：基于statement和row两种模式的混合复制，一般的复制使用statement模式保存binlog，对于statement模式无法复制的操作使用row模式保存binlog。

二、redo log

redo log简介：记录事务对数据页做了哪些修改。

redo log设计背景：mysql保持一致性的做法是，每次在事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

1.Innodb以页为单位进行磁盘交互，而一个事务很可能只修改一个数据页里面的几个字节，此时将完整的数据页刷到磁盘，很浪费资源

2.一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能差。

redo log包括两个部分：内存中的日志缓冲（redo log buffer），和磁盘上的日志文件(redo log file)。mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file.

三、undo log

undo log简介：主要记录数据的逻辑变化，对于每个执行的语句，都有一条相反的undo log，这样在回滚事务的时候，就能恢复之前的数据状态。同时，undo log也是MVCC实现的关键。