Binlog
binlog是用于记录数据库执行的写入操作(不包括查询)，以二进制日志的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由server层进行记录，使用任何存储引擎都会记录mysql binlog日志。
逻辑日志：可以理解为记录的就是SQL语句。
物理日志：mysql数据最终是保存在数据页中，物理日志记录的是数据页的变更。
binlog是通过追加方式写入，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件达到指定给定值时，会生成新的文件。
Binlog使用场景：
1.主从复制：在master端开启binlog，然后将binlog推送给slave端，slave端重放binlog，从而达到数据一致性。
2.数据恢复：通过mysqlbinlog恢复数据
Binlog刷盘机制
对于innodb存储引擎，只有事务在提交时才会记录binlog，此时记录还在内存中，mysql通过sync_binlog参数控制binlog的刷盘时机，取值是0-N
1.sync_binlog=0 不去强制要求，由系统自行判断何时写入磁盘
2.sync_binlog=1 每次commit时候都要写入磁盘
3.sync_binlog=N 每N个事务，才会将binlog写入磁盘
Binlog日志格式
binlog日志格式有三种：分别为：
1.STATEMENT
2.ROW
3.MIXED
STATEMENT：基于SQL语句复制( statement-based replication, SBR )，每一条修改数据的SQL语句记录到binlog中。
1.优点：不需要记录每一行的变化，减少了binlog日志数量，节约了IO，从而提高了性能。
2.缺点：在某些情况下，会导致主从数据不一致，比如执行sysdate()，sleep()等
ROW：基于行的复制（row-based replication, RBR），不记录每条SQL的上下文信息，仅需记录哪条数据被修改。
1.优点：不会出现某些特定情况下的存储过程、函数（function），触发器（trigger）的调用和触发无法被正确复制的问题。
2.缺点：会产生大量的日志，尤其是alter table操作。
MIXED：基于STATEMENT 和 ROW 两种模式的混合（mixed-based replication, MBR），一般的复制使用STATEMENT模式保存binlog，对于STATEMENT无法复制的使用ROW模式保存binlog。
REDO LOG
mysql 事务四大特性中有一个是持久性，只要事务提交成功，那么对数据做的修改就被永久保存下来，不可能因为其他原因恢复到原来的状态。
redo log 包括两部分：一个是内存中的缓存日志（redo log buffer），另一个是磁盘上的日志文件（redo logfile）
mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性的将多个操作记录写到redo logfile。这种先写日志，再写磁盘，就是mysql中的WAL（Write-Ahead Logging）技术。
在计算机操作系统中，用户空间（user space）下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核（kernel space）缓冲区（OS buffer）
因此，redo log buffer写入redo logfile，是先写入OS BUFFER,然后再通过调用fsync() 将其刷到redo logfile中。
MySQL 支持三种将redo log buffer 写入redo logfile的时机，可以通过innodb_flush_log_at_trx_commit参数控制。
1.innodb_flush_log_at_trx_commit=0 延迟写；事务提交时不会将redo log buffer 中日志写入os buffer，而是每秒写入os buffer 并调用fsync()写入到redo logfile中。也就是说，设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟数据。
2.innodb_flush_log_at_trx_commit=1 实时写，实时刷；事务每次提交都会将redo log buffer中的日志写入os buffer，并调用fsync()到redo logfile中，系统崩溃，不会丢失数据，IO性能差。
3.innodb_flush_log_at_trx_commit=2 实时写，延迟刷；每次提交仅写入到os buffer，然后通过调用fsync()将os buffer 中的日志写入到redo logfile中。
Redo log 与 Binlog 区别
1.redo log大小是固定，binlog可通过参数max_binlog_size修改
2.redo log是innodb存储引擎层实现的，并不是所有引擎都有；binlog 是server层实现的，所有存储引擎都可以使用
3.redo log采用循环方式写，binlog通过追加方式写
4.redo log适用于崩溃恢复，binlog适用于主从复制和数据恢复
Undo log
数据库事务四大特性中有一个是原子性 ，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况 。
实际上， 原子性 底层就是通过 undo log 实现的。undo log主要记录了数据的逻辑变化，比如一条 INSERT 语句，对应一条DELETE 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。
同时， undo log 也是 MVCC(多版本并发控制)实现的关键。
