MySQL中有以下日志文件，分别是：
1：错误日志（errorlog）
2：一般查询日志（general log）
3：慢查询日志（slow query log）
4：二进制日志（binlog）
5：中继日志（relay log）
6：重做日志（redo log）
7：回滚日志（undo log）
其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。
一、错误日志（error log）
错误日志介绍
MySQL的错误日志用于记录MySQL服务进程mysqld在启动/关闭或运行过程中遇到的错误信息。
错误日志产生
MySQL的错误日志通常由mysqld或mysqld_safe程序产生
错误日志配置
方法1：启动命令可以使用" --log-error=[file_name] "来指定mysqld记录的错误日志文件，如果没有指定file_name，则默认的错误日志文件为datadir目录下的 `hostname`.err ，hostname表示当前的主机名。
方法2：在my.cnf配置文件中调整，注意，是在[mysqld_safe]或[mysqld]模块的下面进行配置。命令如下：
[mysqld] # /data/mysql/error.err 都是自己手动创建的，记得修改所属的用户与所属的组为mysql ，或者修改操作权限 # chown -R mysql:mysql /data/mysql # chmod -R 755 /data/mysql log-error = /data/mysql/error.err
可以查看变量log_error来查看，命令如下：
mysql> show variables like 'log_error'; +---------------+--------------------------------+ | Variable_name | Value | +---------------+--------------------------------+ | log_error | /data/logs/mysql-log/error.log | +---------------+--------------------------------+ 1 row in set (0.01 sec)
错误日志查看
以下是MySQL 8.0.12 启动的日志信息。
二、一般查询日志（general log）
一般查询日志介绍
查询日志分为一般查询日志和慢查询日志，它们是通过查询是否超出变量 long_query_time 指定时间的值来判定的。
在超时时间内完成的查询是一般查询，可以将其记录到一般查询日志中，但是建议关闭这种日志（默认是关闭的），超出时间的查询是慢查询，可以将其记录到慢查询日志中。
一般查询日志产生
在客户端使用sql查询的时候，mysql服务端会产生查询日志
一般查询日志配置
方法1: 命令启动时，使用" --general_log={0|1} "来决定是否启用一般查询日志，使用" --general_log_file=file_name "来指定查询日志的路径。不给定路径时默认的文件名以 `hostname`.log 命名。
方法2: 在my.cnf配置文件中调整
# 开启一般查询日志，默认off关闭 general_log=on # 指定一般查询日志路径 general_log_file=/data/logs/mysql-log/general.log
可以查看变量general_log%来查看，命令如下：
mysql> show variables like 'general_log%';
+------------------+----------------------------------+
| Variable_name | Value |
+------------------+----------------------------------+
| general_log | ON |
| general_log_file | /data/logs/mysql-log/general.log |
+------------------+----------------------------------+
和查询日志有关的变量有
# 指定慢查询超时时长，超出此时长的属于慢查询，会记录到慢查询日志中 long_query_time = 10 # 定义一般查询日志和慢查询日志的输出格式，不指定时默认为file log_output={TABLE|FILE|NONE}
一般查询日志查看
三、慢查询日志（slow query log）
慢查询日志介绍
查询超出变量 long_query_time 指定时间值的为慢查询。但是查询获取锁(包括锁等待)的时间不计入查询时间内。
慢查询日志产生
mysql记录慢查询日志是在查询执行完毕且已经完全释放锁之后才记录的，因此慢查询日志记录的顺序和执行的SQL查询语句顺序可能会不一致(例如语句1先执行，查询速度慢，语句2后执行，但查询速度快，则语句2先记录)。
慢查询日志配置
方法1: 在my.cnf配置文件中调整
# 是否启用慢查询日志，默认不启用 slow_query_log={1|ON|0|OFF} # 默认路径为库文件目录下主机名加上-slow.log slow_query_log_file=/mydata/data/hostname-slow.log # 指定慢查询超时时长(默认10秒)，超出此时长的属于慢查询 long_query_time=10 # 定义一般查询日志和慢查询日志的输出格式，默认为file log_output={TABLE|FILE|NONE} # 查询没有使用索引的时候是否也记入慢查询日志，默认OFF log_queries_not_using_indexes=OFF
可以查看变量slow_query_log%来查看，命令如下：
mysql> show variables like 'slow_query_log%'; +---------------------+--------------------------------------------------------+ | Variable_name | Value | +---------------------+--------------------------------------------------------+ | slow_query_log | OFF | | slow_query_log_file | /data/soft/mysql-8.0.12-el7-x86_64/data/H__D2-slow.log | +---------------------+--------------------------------------------------------+ 2 rows in set (0.00 sec)
慢查询日志查看
四、二进制日志（bin log）
二进制日志介绍
二进制日志包含了引起或可能引起数据库改变(如delete语句但没有匹配行)的事件信息，但绝不会包括select和show这样的查询语句。语句以"事件"的形式保存，所以包含了时间、事件开始和结束位置等信息。
二进制日志是以事件形式记录的，不是事务日志(但可能是基于事务来记录二进制日志)，不代表它只记录innodb日志，myisam表也一样有二进制日志。
对于事务表的操作，二进制日志只在事务提交的时候一次性写入(基于事务的innodb二进制日志)，提交前的每个二进制日志记录都先cache，提交时写入。
对于事务表来说，一个事务中可能包含多条二进制日志事件，它们会在提交时一次性写入。而对于非事务表的操作，每次执行完语句就直接写入。
mysqld还创建一个二进制日志索引文件，当二进制日志文件滚动的时候会向该文件中写入对应的信息。所以该文件包含所有使用的二进制日志文件的文件名。默认情况下该文件与二进制日志文件的文件名相同，扩展名为'.index'。要指定该文件的文件名使用 --log-bin-index[=file_name] 选项。
当重启mysql服务或刷新日志或者达到日志最大值时，将滚动二进制日志文件，滚动日志时只修改日志文件名的数字序列部分。
二进制日志文件的最大值通过变量 max_binlog_size 设置(默认值为1G)。但由于二进制日志可能是基于事务来记录的(如innodb表类型)，而事务是绝对不可能也不应该跨文件记录的，如果正好二进制日志文件达到了最大值但事务还没有提交则不会滚动日志，而是继续增大日志，所以 max_binlog_size 指定的值和实际的二进制日志大小不一定相等。
因为二进制日志文件增长迅速，但官方说明因此而损耗的性能小于1%，且二进制目的是为了恢复定点数据库和主从复制，所以出于安全和功能考虑，极不建议将二进制日志和datadir放在同一磁盘上。
二进制日志产生
事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
二进制日志配置
二进制日志默认时开启的，可以通过 show variables like '%log_bin%'; 查看是否开启，以下是指定binlog日志文件名
方法1: 命令启动时，使用" --log_in=binlog" 赋值来指定binlog日志的文件名,开启binlog日志
方法2: 在my.cnf配置文件中调整
1 # 赋值来指定binlog日志的文件名,开启二进制日志 2 log_bin = /data/logs/mysql-log/binlog/binlog
二进制日志查看
binlog 的配置信息：show variables like '%log_bin%';
binlog 的格式：show variables like 'binlog_format';
日志的文件列表：show binary logs;
当前日志的写入状态：show master status;
清空 binlog 日志：reset master;
mysql> show variables like '%log_bin%'; +---------------------------------+------------------------------------------+ | Variable_name | Value | +---------------------------------+------------------------------------------+ | log_bin | ON | | log_bin_basename | /data/logs/mysql-log/binlog/binlog | | log_bin_index | /data/logs/mysql-log/binlog/binlog.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | sql_log_bin | ON | +---------------------------------+------------------------------------------+ 6 rows in set (0.00 sec)
查看binlog日志命令： mysqlbinlog /data/logs/mysql-log/binlog/binlog.000001
[root@H__D2 ~]# mysqlbinlog /data/logs/mysql-log/binlog/binlog.000001; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #210505 18:11:52 server id 1 end_log_pos 124 CRC32 0xc4ac9366 Start: binlog v 4, server v 8.0.12 created 210505 18:11:52 at startup # Warning: this binlog is either in use or was not closed properly. ROLLBACK/*!*/; BINLOG ' aG+SYA8BAAAAeAAAAHwAAAABAAQAOC4wLjEyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABob5JgEwANAAgAAAAABAAEAAAAYAAEGggAAAAICAgCAAAACgoKKioAEjQA CgFmk6zE '/*!*/; # at 124 #210505 18:11:52 server id 1 end_log_pos 155 CRC32 0x4a0e84b6 Previous-GTIDs # [empty] # at 155 #210505 18:17:53 server id 1 end_log_pos 230 CRC32 0x8a51b856 Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1620209873720931 immediate_commit_timestamp=1620209873720931 transaction_length=308 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; # original_commit_timestamp=1620209873720931 (2021-05-05 18:17:53.720931 CST) # immediate_commit_timestamp=1620209873720931 (2021-05-05 18:17:53.720931 CST) /*!80001 SET @@session.original_commit_timestamp=1620209873720931*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 230 #210505 18:17:53 server id 1 end_log_pos 314 CRC32 0x7eaa39b9 Query thread_id=8 exec_time=0 error_code=0 SET TIMESTAMP=1620209873/*!*/; SET @@session.pseudo_thread_id=8/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1168113696/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8mb4 *//*!*/; SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; /*!80005 SET @@session.default_collation_for_utf8mb4=255*//*!*/; BEGIN /*!*/; # at 314 #210505 18:17:53 server id 1 end_log_pos 372 CRC32 0x335603d9 Table_map: `test`.`user` mapped to number 62 # at 372 #210505 18:17:53 server id 1 end_log_pos 432 CRC32 0x4fd1e95f Update_rows: table id 62 flags: STMT_END_F BINLOG ' 0XCSYBMBAAAAOgAAAHQBAAAAAD4AAAAAAAEABHRlc3QABHVzZXIAAgMPAoAAAgEBAAID/P8A2QNW Mw== 0XCSYB8BAAAAPAAAALABAAAAAD4AAAAAAAEAAgAC//8AAQAAAAblsI/nmb0AAQAAAAblpKfnmb1f 6dFP '/*!*/; # at 432 #210505 18:17:53 server id 1 end_log_pos 463 CRC32 0x9afadbaf Xid = 12 COMMIT/*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
五、中继日志（relay log）
中继日志介绍
从数据库Slave服务的I/O线程从主数据库Master服务的二进制日志中读取数据库的更改记录并写入到中继日志中，然后在Slave数据库执行修改操作。这就是中继日志Relay Log。
中继日志产生
同上
中继日志配置
配置中继日志的文件名
# 配置中继日志的文件名,开启中继日志 relay-log=/data/logs/mysql-log/relaylog
相关参数
mysql> show variables like '%relay%'; +---------------------------+---------------------------------------------------------------+ | Variable_name | Value | +---------------------------+---------------------------------------------------------------+ | max_relay_log_size | 0 | | relay_log | H__D2-relay-bin | | relay_log_basename | /data/soft/mysql-8.0.12-el7-x86_64/data/H__D2-relay-bin | | relay_log_index | /data/soft/mysql-8.0.12-el7-x86_64/data/H__D2-relay-bin.index | | relay_log_info_file | relay-log.info | | relay_log_info_repository | TABLE | | relay_log_purge | ON | | relay_log_recovery | OFF | | relay_log_space_limit | 0 | | sync_relay_log | 10000 | | sync_relay_log_info | 10000 | +---------------------------+---------------------------------------------------------------+ 11 rows in set (0.00 sec)
中继日志参数说明
relay_log 中继日志存储位置和文件名
relay_log_info_file 记录master数据库二进制日志的pos和中继日志的pos
max_relay_log_size 中继日志的文件最大SIZE
relay_log_purge 是否自动清理中继日志
relay_log_recovery 中继日志自动恢复
relay_log_space_limit 中继日志空间限制
sync_relay_log 中继日志同步方式
sync_relay_log_info 主从复制状态记录文件info_file更新方式
中继日志查看
查看中继日志命令： mysqlbinlog H__D-relay-bin.000001
[root@H__D2 data]# mysqlbinlog H__D-relay-bin.000001 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #210505 15:30:12 server id 1 end_log_pos 124 CRC32 0x8d7ef9ef Start: binlog v 4, server v 8.0.12 created 210505 15:30:12 # This Format_description_event appears in a relay log and was generated by the slave thread. # at 124 #210505 15:30:12 server id 1 end_log_pos 155 CRC32 0x4700fe0d Previous-GTIDs # [empty] # at 155 #210505 15:30:12 server id 1 end_log_pos 178 CRC32 0xb55d9865 Stop SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
六、重做日志（redo log）
undo log 和 redo log 其实都不是 MySQL 数据库层面的日志，而是 InnoDB 存储引擎的日志。二者的作用联系紧密，事务的隔离性由锁来实现，原子性、一致性、持久性通过数据库的 redo log 或 redo log 来完成。redo log 又称为重做日志，用来保证事务的持久性，undo log 用来保证事务的原子性和 MVCC。
重做日志介绍
如果每一次更新都写磁盘，然后磁盘也要找到对应记录，再更新，整个过程的IO成本和查找成本都很高。所以InnoDB采取WAL（Write-Ahead Logging）技术，即先写日志，再写磁盘。
当有记录需要更新时，InnoDB引擎先记录redo log，再更新内存。然后找适当时机将该操作写到磁盘（比如系统空闲时）。
redo log的大小是固定的（可配置），比如4个文件，每个文件大小1GB，从第一个文件开始写，写到第四个文件末尾再从头循环。
确保事务的持久性。redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
重做日志产生
事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。
重做日志配置
默认情况下，对应的物理文件位于数据库的data目录下的 ib_logfile1 和 ib_logfile2
innodb_log_group_home_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2
关于文件的大小和数量，由以下两个参数配置：
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1
mysql> show variables like 'innodb_log_file_size'; +----------------------+----------+ | Variable_name | Value | +----------------------+----------+ | innodb_log_file_size | 50331648 | +----------------------+----------+ 1 row in set (0.00 sec)
重做日志查看
ib_logfile1 和 ib_logfile2 为 二进制文件
七、回滚日志（undo log）
回滚日志介绍
保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
回滚日志产生
事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性
回滚日志配置
MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。
MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数
如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。
关于MySQL5.7之后的独立undo 表空间配置参数如下：
innodb_undo_directory = /data/undospace/ –undo独立表空间的存放目录 innodb_undo_logs = 128 –回滚段为128KB innodb_undo_tablespaces = 2 –指定有2个undo log文件
如果undo使用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目录下面，其属性由参数innodb_data_file_path配置。
mysql> show variables like 'innodb_data_file_path'; +-----------------------+------------------------+ | Variable_name | Value | +-----------------------+------------------------+ | innodb_data_file_path | ibdata1:12M:autoextend | +-----------------------+------------------------+ 1 row in set (0.00 sec)
mysql> show variables like '%undo%'; +--------------------------+------------+ | Variable_name | Value | +--------------------------+------------+ | innodb_max_undo_log_size | 1073741824 | | innodb_undo_directory | ./ | | innodb_undo_log_encrypt | OFF | | innodb_undo_log_truncate | ON | | innodb_undo_tablespaces | 2 | +--------------------------+------------+ 5 rows in set (0.00 sec)
回滚日志查看
ibdata1 为二进制文件
参考：https://www.cnblogs.com/f-ck-need-u/p/9001061.html#auto_id_4
参考：https://www.cnblogs.com/myseries/p/10728533.html
