MySQL 相关日志介绍
一. Redo Log
Redo Log是InnoDB存储引擎层的日志，和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL，即在持久化数据文件前，保证之前的redo日志已经写到磁盘。
Redo log文件以ib_logfile[number]命名，以顺序的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。
Redo Log 作用：
- 保证事务的持久性，即只要事务提交后数据就固化在磁盘，不会丢失。
- 以顺序追加的方式记录Redo Log,从而改善性能。
- MySQL 非正常关闭启动后根据Redo Log 恢复已经提交数据。
二. Undo Log
Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用于实现多版本并发控制(MVCC)。
MVCC: Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着undo链找到满足其可见性的记录。MVCC可以实现读写不冲突这一个特性，极大的提高数据库性能，以至于现在主流的数据库基本都实现了MVCC(除了SQL SERVER，默认隔离级别下不能实现MVCC，所以才会经常出现阻塞！！！)。
Undo log 作用：
- 保证事务的原子性，即事务中的所有操作必须全部完成或者全部回滚。
- 实现了MVCC特性，提高数据库的并发性。
- MySQL 非正常关闭启动后根据Undo log 回滚未提交的数据。
三. BinLog
BinLog 是MySQL Server层记录的二进制日志文件，用于记录MySQL的数据更新或者潜在更新(比如DELETE语句执行删除而实际并没有符合条件的数据)，select或show等不会修改数据的操作不会记录在binlog中。
BinLog 作用：
- 实现主从复制功能。
- 用来查看数据库的变更历史（具体时间点变更操作)。
- 用于数据恢复，闪回某段时间的数据或是结合备份恢复数据到某一时刻（binlog的数据恢复都是需要人为干预的，并非像undo、redo一样是MySQL自动维护的）
- 用于增量备份。
Redolog 和 BinLog 都是记录SQL变化的源数据，为什么不用Redolog来实现主从复制呢？主要原因是MySQL的特点就是支持多存储引擎，为了兼容绝大部分引擎来支持复制这个特性，那么自然要采用MySQL Server层记录的日志而不是仅仅针对InnoDB的Redolog，因为如果采用了InnoDB Redolog复制，那么其他引擎也想复制，此时该怎么办呢？
四. SlowLog
慢查询日志(SlowLog)记录MySQL中响应时间超过指定阀值的SQL语句，运行时间超过long_query_time值的SQL，会被记录到慢查询日志中。SQL性能调优时，才会暂时开启。
五. ErrorLog
错误日志(ErrorLog)记录了MySQL数据库启动关闭信息，以及服务器运行过程中所发生的任何严重的错误信息。通常，当MySQL无法正常启动或者发生Crash，首先想到的就是查看错误日志，从日志中我们可以找错误信息，以此来排查问题。
六. General Log
一般查询日志(General Log)记录服务器从客户端接收的所有命令，以接收的顺序将其记录在日志中。这个日志对性能的影响比较大，毕竟将所有的命令都记录了下来，只有在排查个别问题时，才会暂时打开。
图例：
