“这是我参与更文挑战的第4天，活动详情查看： 更文挑战”
先说一下产生日志的位置。 binlog是sql层产生的，redo、undo是引擎层产生的,所以binlog日志先于redo undo 被记录。
1.binlog
binlog日志使用场景
1>.主从数据库之间同步。
2>.数据的恢复。
binlog记录的内容
binlog记录操作的方法是逻辑性的语句。
binlog是记录所有数据库表结构变更（例例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）。
binlog日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文 件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
mysql的binlog有3种记录模式STATEMENT，ROW，MIXED
1.1 Row Level 行模式
日志中会记录每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
优点： 在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记 录那一条被修改。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。不会出现某 些特定的情况下的存储过程或function，以及trigger的调用和触发无法被正确复制的问题 缺点：row level，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，会产 生大量的日志内容。
1.2 Statement Level（默认）
每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来 master端执行过的相同的sql来再次执行
优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行行数据的变化， 减少bin-log日志量，节约IO，提高性能，因为它只需要在Master上执行语句的细节，以及执行 语句上下文的信息。 缺点：由于只记录语句，所以，在statement level下 已经发现了有不少情况会造成MySQL的复制出 现问题，主要是修改数据的时候使用了某些定的函数或者功能的时候会出现。
1.3 Mixed ⾃自动模式
在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志格式，也就是在 Statement和Row之间选择一种。如果sql语句确实就是update或者delete等修改数据的语句，那么 还是会记录所有行的变更。
redo log与binlog不同
redo log最重要的是保证了事务特性中的持久性。
我们知道，在MySQL中还存在binlog(二进制日志)也可以记录写操作并用于数据的恢复，但二者是有 着根本的不同的： （1）作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是 用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。
（2）层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的SQL层
（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据 binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。
（4）写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元： 前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略略，修改 innodb_flush_log_at_trx_commit参数可以改变该策略略，但事务的持久性将无法保证。 除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘⼀一次redo log等，这样的好处是不 一定要等到commit时刷盘，commit速度大大加快。
undo log 记录了与redo log逻辑相反内容，便于回滚。
