1 Mysql中的日志文件

redo log
重做日志
undo log
回滚日志
binlog
二进制日志
slow query log
慢查询日志
error log
错误日志
general log
一般查询日志
relay log
中继日志

1.1 redo log

1.1.1 用途

事物持久性
重做日志：保证事物的持久性 Consistence
节点故障时，可能有脏页未写入磁盘，mysql服务重启时，根据redo log重做，保证持久性

1.1.2 系统变量

innodb_log_buffer_size
innodb日志缓冲区大小
innodb_log_group_home_dir
日志文件组路径默认./ 表示数据库data目录下
innodb_log_files_in_group
文件数量默认2

物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2

1.1.3 写盘

事物开始后，redo log就开始写入日志文件，而不是在事物提交时才开始，这也就很好地解释再大的事务提交（commit）也是很快的

InnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。然而，如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销（顺序IO，当然很快），以及数据库启动时恢复操作所需的时间

1.2 undo log

1.2.1 用途

MVCC + 回滚

1.2.2 undo log 事务开始之前生成，也会产生 redo 来保证undo log的可靠性

MySQL5.6之前，undo log存储在共享表空间ibdata的回滚段中，MySQL5.7之后可以指定uodo表空间 innodb_undo_directory undo独立表空间的存放目录

1.2.3 逻辑日志

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。
当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。
另外，undo log也会产生redo log，因为undo log也要实现持久性保护。

1.3 binlog

1.3.1 用途

主从复制
数据库基于时间点还原

1.3.2 数据库层面的日志

和innodb无关
事物提交的时候产生，是逻辑日志
expire_logs_days 配置删除时间
log_bin_basename 配置binlog文件路径

参考资料

https://www.cnblogs.com/wy123/p/8365234.html
https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html#auto_id_13
https://blog.csdn.net/qq_36652619/article/details/89715191

Mysql log 日志文件