1.错误日志（errorlog）

错误日志记录着 mysqld 启动和停止，以及服务器在运行过程中发生的错误及警告相关信息。当数据库意外宕机或发生其他错误时，我们应该去排查错误日志。

log_error 参数控制错误日志是否写入文件及文件名称，默认情况下，错误日志被写入终端标准输出stderr。当然，推荐指定 log_error 参数，自定义错误日志文件位置及名称。

# 指定错误日志位置及名称
vim /etc/my.cnf 
[mysqld] 
log_error = /data/mysql/logs/error.log
相关配置变量说明：
log_error={1 | 0 | /PATH/TO/ERROR_LOG_FILENAME}
定义错误日志文件。作用范围为全局或会话级别，属非动态变量。

2.慢查询日志（slow query log）

慢查询日志是用来记录执行时间超过 long_query_time 这个变量定义的时长的查询语句。通过慢查询日志，可以查找出哪些查询语句的执行效率很低，以便进行优化。
与慢查询相关的几个参数如下：

**slow_query_log ：是否启用慢查询日志，默认为0，可设置为0，1。

**slow_query_log_file ：指定慢查询日志位置及名称，默认值为host_name-slow.log，可指定绝对路径。

**long_query_time ：慢查询执行时间阈值，超过此时间会记录，默认为10，单位为s。

log_output ：慢查询日志输出目标，默认为file，即输出到文件。

默认情况下，慢查询日志是不开启的，一般情况下建议开启，方便进行慢SQL优化。在配置文件中可以增加以下参数：

# 慢查询日志相关配置，可根据实际情况修改
vim /etc/my.cnf 
[mysqld] 
slow_query_log = 1
slow_query_log_file = /data/mysql/logs/slow.log
long_query_time = 3
log_output = FILE

3.一般查询日志（general log）

一般查询日志又称通用查询日志，是 MySQL 中记录最详细的日志，该日志会记录 mysqld 所有相关操作，当 clients 连接或断开连接时，服务器将信息写入此日志，并记录从 clients 收到的每个 SQL 语句。当你怀疑 client 中的错误并想要确切知道 client 发送给mysqld的内容时，通用查询日志非常有用。

默认情况下，general log 是关闭的，开启通用查询日志会增加很多磁盘 I/O，所以如非出于调试排错目的，不建议开启通用查询日志。相关参数配置介绍如下：

# 慢查询日志相关配置，可根据实际情况修改
vim /etc/my.cnf 
[mysqld] 
slow_query_log = 1
slow_query_log_file = /data/mysql/logs/slow.log
long_query_time = 3
log_output = FILE

4.二进制日志（binlog）

它记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。常用于数据恢复和主从复制。

与 binlog 相关的几个参数如下：

**log_bin ：指定binlog是否开启及文件名称。

**server_id ：指定服务器唯一ID，开启binlog 必须设置此参数。

**binlog_format ：指定binlog模式，建议设置为ROW。

**max_binlog_size ：控制单个二进制日志大小，当前日志文件大小超过此变量时，执行切换动作。

**expire_logs_days ：控制二进制日志文件保留天数，默认值为0，表示不自动删除，可设置为0~99。

binlog默认情况下是不开启的，不过一般情况下，建议开启，特别是要做主从同步时。

# binlog 相关配置
vim /etc/my.cnf 
[mysqld]
server-id = 1003306
log-bin = /data/mysql/logs/binlog
binlog_format = row
expire_logs_days = 15

5.中继日志(relay log)

用于主从复制架构中的从服务器上，从服务器的 slave 进程从主服务器处获取二进制日志的内容并写入中继日志，然后由 IO 进程读取并执行中继日志中的语句。
relay log 相关参数一般在从库设置，几个相关参数介绍如下：

**relay_log ：定义 relay log 的位置和名称。

**relay_log_purge ：是否自动清空不再需要中继日志，默认值为1(启用)。

relay_log_recovery ：当 slave 从库宕机后，假如 relay log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay log ，并且重新从 master 上获取日志，这样就保证了 relay log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为1可开启此功能。

relay log 默认位置在数据文件的目录，文件名为 host_name-relay-bin，可以自定义文件位置及名称。

# relay log 相关配置,从库端设置
vim /etc/my.cnf 
[mysqld]
relay_log = /data/mysql/logs/relay-bin
relay_log_purge = 1
relay_log_recovery = 1

6. 重做日志（redo log）

我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么 MySQL 是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

因为 Innodb 是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了。
一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机 IO 写入性能太差。

因此 MySQL 设计了 redo log ，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
redo log 包括两部分：一个是内存中的日志缓冲（redo log buffer），另一个是磁盘上的日志文件（redo log file）。MySQL 每执行一条 DML 语句，先将记录写入 redo log buffer ，后续某个时间点再一次性将多个操作记录写到 redo log file 。
默认情况下，redo log 在磁盘上由名为 ib_logfile0 和 ib_logfile1 的两个物理文件展示。redo log 相关参数简单介绍如下：

innodb_log_files_in_group：redo log 文件的个数，命名方式如：ib_logfile0，iblogfile1… iblogfilen。默认2个，最大100个。
innodb_log_file_size：单个 redo log 文件设置大小，默认值为 48M，最大值为512G，注意最大值指的是整个 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。
innodb_log_group_home_dir：指定 redo log 文件组所在的路径，默认./ ，表示在数据库的数据目录下。
innodb_log_buffer_size：redo log buffer 大小，默认16M。延迟事务日志写入磁盘，把 redo log 放到该缓冲区，然后根据 innodb_flush_log_at_trx_commit 参数的设置，再把日志从 buffer 中 flush 到磁盘中。
innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盘的策略，默认为1。值为1，每次 commit 都会把 redo log 从 redo log buffer 写入到 system ，并 fsync 刷新到磁盘文件中。值为2，每次事务提交时 MySQL 会把日志从 redo log buffer 写入到 system ，但只写入到 file system buffer，由系统内部来 fsync 到磁盘文件。如果数据库实例 crash ，不会丢失 redo log，但是如果服务器 crash，由于 file system buffer 还来不及 fsync 到磁盘文件，所以会丢失这一部分的数据。值为0，表示事务提交时不进行写入 redo log 操作，这个操作仅在 master thread 中完成，而在 master thread 中每1秒进行一次重做日志的 fsync 操作，因此实例 crash 最多丢失1秒钟内的事务。

更改 redo log 及其 buffer 大小是需要重启数据库实例的，建议初始化时做好评估。可以适当加大 redo log 组数和大小，特别是你的数据库实例更新比较频繁的情况下。但也不推荐 redo log 设置过大。

redo log 是在崩溃恢复期间使用的disk-based数据结构，用于纠正由不完整的transactions写入的数据。
用来存储 MySQL 在 DML 操作时的数据页变化过程及 LSN(日志序列号),属于物理日志。
redo log 是 InnoDB 引擎特有的。
redo log 是循环写的，空间固定会用完

7.回滚日志（undo log）

undo log 主要用于保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚。比如一条 INSERT 语句，对应一条 DELETE 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。同时，undo log 也是 MVCC (多版本并发控制) 实现的关键。
MySQL 5.7 版本中，undo log 默认存放在共享表空间 ibdata 中。也可以在初始化时通过配置参数改成独立的文件，简单介绍几个 undo log 相关参数：

innodb_max_undo_log_size：控制最大 undo tablespace 文件的大小，当启动了innodb_undo_log_truncate 时，undo tablespace 超过 innodb_max_undo_log_size 阀值时才会去尝试truncate。该值默认大小为1G，truncate后的大小默认为10M。
innodb_undo_tablespaces：设置 undo 独立表空间个数，范围为0-128，5.7版本默认为0，0表示不开启独立undo表空间。该参数只能在最开始初始化 MySQL 实例的时候指定。
innodb_undo_directory：设置 undo 表空间的存放目录，默认数据目录。
innodb_undo_log_truncate：设置 undo 表空间是否自动截断回收。该参数生效的前提是，已设置独立表空间且独立表空间个数大于等于2个。

undo log 相关参数一般很少改动。MySQL 8.0 默认启用了独立表空间，可能 undo log 表空间的大小设置更灵活些。

MySQL日志模块详解-4