mysql有如下几种不同的日志：
- 错误日志
- 二进制日志（Binlog日志）
- 查询日志
- 慢查询日志
- 事务日志（innoDB独有，主要有undo log和redolog）
错误日志
记录了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息，当mysql出现故障导致无法正常启动的时候，可以首先查看此日志
该日志是默认开启的，默认存放目录是mysql的数据目录(/var/lib/mysql)，默认的日志文件名为hostname.err(hostname是主机名)
查看日志位置指令show variables like 'log_error%'
然后可以查看日志文件
二进制日志（binlog日志）
binlog日志记录了所有的DDL（数据定义语言create table）语句和DML（数据操作语言insert,update,delete）语句，但是不包括数据查询语句。此日志对于数据容灾恢复极其重要，mysql的主从复制基于binlog实现
binlog日志默认没有开启，需要到mysql的配置文件中开启，并配置mysql日志的格式
windows下的mysql配置文件my.ini，linux下的mysql配置文件my.cnf，示例在windows的my.ini结尾处添加如下配置
# 配置开启binlog日志，日志的文件前缀为mysqlbin即生成的binlog文件名格式如：mysqlbin.00001,mysqlbin.00002
log_bin=mysqlbin
# 配置binlog日志的格式
binlog_format=STATEMENT
binlog日志的格式
- STATEMENT
-该日志格式在日志文件中记录的都是SQL语句（statement），每一条对数据进行修改的sql都会记录在日志文件中，通过mysql提供的mysqlbinlog工具，可以清晰的查看到每条语句的文本。主从复制的时候，从库slave会将日志解析为原文本，并在从库中重新执行一遍 - ROW
该日志格式在日志文件中记录的是每一行的数据变更，而不是记录sql语句。比如，执行sql语句：update tb_test set status=1,如果是STATAMENT日志格式，在日志中会记录一行sql，如果是ROW，由于是对全表进行更新，所以每一行记录都会发生变更，ROW格式中会记录每一行的数据变更 - MIXED
这是目前mysql默认的日志格式，即混合了STATEMENT和ROW两种格式，默认情况下使用STATEMENT，但是在一些特殊情况下采用ROW来进行记录，MIXED格式能尽量利用两种模式的优点，而避开他们的缺点
查看STATEMENT格式日志
配置如上，然后重启mysql服务，linux下service mysql restart
然后选择如下表
添加一行记录
insert into employees values(null,'JERRY',18,'dev','2020-08-13 22:20:02')
添加成功以后查看binlog日志文件，默认存储在mysql的数据目录下，如下图的红圈部分就是mysql的binglog文件
mysqlbin.index：该文件是日志索引文件，记录当前包含了几个binlog文件，日志名是什么
mysqlbinlog.000001：具体的binlog日志文件，直接打开是无法查看的，因为数据的存储形式是二进制，因此我们需要使用mysqlbinlog工具来查看，格式mysqlbinlog 日志名：
mysqlbinlog mysqlbin.000001
其他都是注释信息，只需要看红框中的这一行sql语句即可
查看ROW格式日志
将上面添加的配置中的binlog_format更改为ROW
然后执行更新语句update employees set position='test'
将上面表中所有人的岗位更新为test，然后来查看日志更新,发现多了mysqlbin.000002文件
然后通过mysqlbinlog mysqlbin.000002查看文件
发现红框中的日志并不是我们期望的update类型的能看懂的数据，因此我们重新使用mysqlbinlog -vv mysqlbin.000002来查看
对于InnoDB引擎而言，在每次事务commit提交时才会记录bin log日志，此时记录仍然在内存中，那么什么时候存储到磁盘中呢？
mysql通过sync_binlog参数控制bin log刷盘时机，取值范围：0～N
- 0：不去强求，由系统自行判断何时写入磁盘；
- 1：每次事务commit的时候都要将bin log写入磁盘；
- N：每N个事务commit，才会将bin log写入磁盘；
sync_binlog 参数建议设置为1，这样每次事务commit时就会把bin log写入磁盘中，这样也可以保证mysql异常重启之后bin log日志不会丢失
日志删除
对于比较繁忙的时候，由于每天生成日志量大，这些日志如果长时间不清除，将会占用大量磁盘空间，下面是集中删除日志的方式
方式1：通过Reset Master指令删除全部binlog日志，删除之后，日志编号，将从xxxx.000001重新开始，会重新生成一个xxxx.000001的空日志文件
Reset Master
方式2：执行指令purge master logs to 'mysqlbin ******'，该命令将删除******编号之前的所有日志
方式3：执行指令purge master logs before 'yyyy-mm-dd hh24:mi:ss'，该命令将删除日志为"yyyy-mm-dd hh24:mi:ss“之前产生的所有日志
方式4：设置参数--expire_logs_days=#，此参数的含义是设置日志的过期天数，过了指定的天数后日志将会被自动删除，配置如下：
log_bin=mysqlbin
binlog_format=MIXED
--expire_logs_days=3
查询日志
查询日志中记录了客户端的所有操作语句，而binlog日志中不包含查询的sql语句，默认情况下，查询日志未开启，如果需要开启查询日志，windows中my.ini，linux中my.cnf中添加如下配置
# 该选项用于开启查询日志, 0关闭 1开启
general_log=1
# 设置查询日志的文件名，缺省情况下为host_name.log
general_log_file=mysql_query.log
配置完毕，在mysql数据库中执行修改查询操作
select * from employees;
select count(*) from employees;
update employees set position='dev'
然后在mysql的数据目录下（刚刚存放binlog日志的地方）
可以在里面看到刚刚执行的所有sql语句
慢查询日志
慢查询日志记录了所有执行时间超过参数long_query_time设置值并且扫描记录数不小于min_examined_row_limit的所有的sql语句的日志，long_query_time默认为10秒，最小为0秒，精度可以到微秒。默认情况下慢查询日志未开启，需要我们手动修改配置文件开启，修改配置如下
# 该参数是用来控制慢查询日志是否开启，1开启 0关闭
slow_query_log=1
# 该参数用来指定慢查询日志的文件名
slow_query_log_file=slow_query.log
# 该选项用来配置查询的时间限制，超过这个时间将被认为是慢查询，将需要进行日志记录，默认为10秒
long_query_time=2
上面配置完以后，会默认生成一个空的慢查询日志文件
和错误日志，查询日志一样，慢查询日志记录的格式也是纯文本，可以直接读取
- 查询我们刚刚设置的long_query_time的值
show variables like 'long_query_time'
- 模拟插入30w+条数据到tb_item测试表，然后执行查询全部和like模糊查询，查看慢查询日志
上面是直接通过mysql的日志内容查看的，我们也可以使用mysqldumpslow命令来查看该日志文件
redo log（重做日志）
mysql的 InnoDB 引擎使用redo log来实现事务的ACID中的D：持久性
InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓冲池(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓存：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；
当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）
Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证
于是，redo log 被引入来解决这个问题：当数据修改时，除了修改Buffer Pool中的数据，还会在 redo log 记录已成功提交事务的修改信息；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。
start transaction;
select balance from bank where name="zhangsan";
// 生成 重做日志 balance=600
update bank set balance = balance - 400;
// 生成 重做日志 amount=400
update finance set amount = amount + 400;
commit;
既然 redo log 也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：
- 刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO。
- 刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无效IO大大减少
undo log（回滚日志）
保证事务ACID中的A：原子性
undo log 叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。
https://www.cnblogs.com/goloving/p/15145138.html
https://www.jianshu.com/p/366a79ee1417/
https://xie.infoq.cn/article/0e5507eca03de807854a9c6dc
