错误日志：
启动、运行、停止 mysqld(MySQL Server) 遇到的问题
通用查询日志：
建立客户端连接和从客户端接收的语句
二进制日志：
更改数据的语句（也用于复制）
中继日志：
从复制master server接收到的数据更改
慢查询日志：
执行查询超过long_query_time 系统变量指定的秒数
DDL日志（元数据日志）：
DDL语句执行的元数据操作
通过刷新日志可以强制服务器关闭并重新打开日志文件（有时还会生成一个新的日志文件）
刷新日志文件方法：
mysql> flush logs;
mysql> mysqladmin flush-logs
mysql> mysqladmin refresh
shell> mysqldump --flush-logs
此外，当二进制日志的大小达到 max_binlog_size 系统变量设置也会刷新该日志
注：官档中提到 mysqldump 的 --master-data 选项也可会刷新日志，测试发现不能
通用查询日志和慢查询日志的一些说明：
log_output 系统变量：控制通用查询日志和慢查询日志输出目标位置，可选值包括：TABLE，FILE，NONE；这些值可以任意组合，NONE的优先级最高
如果将设置log_output='table'，则通用查询日志文件、慢查询日志文件中只会保存系统启动信息
general_log 系统变量：控制是否启用通用日志
general_log_file 系统变量：控制通用日志文件
slow_query_log 系统变量：控制是否启用慢查询日志
slow_query_log_file 系统变量：控制慢查询日志文件
注：如果将通用查询日志和慢查询日志存放在TABLE中，可以通过查询mysql schema下的general_log表以及slow_log表获取日志内容
关于日志表的一些补充：
写到日志表中的条目不会写到二进制日志文件中，所以也不会复制到 SLAVE Server
关于日志表清理方法：可以通过TRUNCAET TABLE语句清理，或者通过一个轮询的方式，比如：
mysql > user mysql;
mysql> create table general_log2 like general_Log;
mysql> drop table general_log to gerneral_log_backup, gerneral_logs2 to general_log;
通过mysqldump命令只会dump日志表的定义，不会dump日志表中的数据，这样在恢复时，可以保证恢复日志表结构
如果日志写到文件当中，可以通过如下方式清理日志文件：
shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory
也可以通过一种通用方式处理：
SET GLOBAL general_log = 'OFF';
shell> mv host_name.log host_name-old.log
SET GLOBAL general_log = 'ON';
在会话级启停通用查询日志，可以通过 sql_log_off 会话变量实现
写在通用查询日志中的密码会被重写，通过在MySQL Server启动时添加 --log-raw 选项密码不会重写，这在排查问题时可能有用，但是不安全，生成中不建议使用
log_timestamps 系统变量：
这个系统变量影响通用查询日志文件、慢查询日志文件、错误日志的显示时间戳，通过存储在日志表中的日志时间戳显示没有影响
log_timestamps 系统变量有两个取值：UTC、SYSTEM
错误日志：
错误日志包含：MySQL Server 启停时间信息，以及在启停和运行过程中的错误、警告、提示信息
如果使用mysqld_safe启用MySQL Server，在mysqld异常终止时，mysqld_safe会重启mysqld并把信息写到错误日志中
在MySQL 8.0 中，错误日志子系统有执行log event过滤以及写log event的组件和控制组件选择的系统变量组成
log_error 系统变量：指定错误日志位置
log_error_verbosity 系统变量：指定错误日志记录等级（0、1、2 分别对应 error、error warning、error warning note）
log_error_services 系统变量：指定过滤组件、写组件
二进制日志：
二进制日志包含描述数据库更改的 events，还包含每个更新语句花费的时间
二进制日志记录对数据库对象做出更改的语句，如果这个语句可能更改数据，比如：delete from table_name where 1=0;在二进制日志格式为STATEMENT时会记录到二进制日志文件中，而二进制日志格式为ROW时则不会记录到二进制日志文件中
二进制日志有两个重要作用：
复制
恢复
二进制日志会对系统产生一些额外的开销，如果MySQL Server不适用复制环境，或者不需要做时间点恢复的话，可以不用开启二进制日志
与二进制日志相关系统变量：
log_bin 系统变量：指定二进制日志的basename
log_slave_updates 系统变量：这个系统变量应用在Slave Server中，在Slave Server应用从Master Server接收的二进制events时，是否将应用的events写到Slave Server自身的二进制日志中
slave_preserve_commit_order 系统变量：这个系统变量也是在Slave Server中使用，而且是在多线程复制Slave Server才有意义
配置多线程复制Slave，设置 slave_parallel_workers 系统变量为非 0 值
可以将 slave_parallel_type 系统变量设置为 Logical Clock，这样对于Master Server端组提交的事务可以在Slave Server端并行化应用接收的events
二进制日志刷新的几种情形：
MySQL Server 启动
flush logs
日志文件大小达到max_binlog_size 系统变量定义的值
注：二进制日志文件大小可能会超过 max_binlog_size 指定的大小，比如：一个大事务写到日志文件，由于事务以 one piece 存储到日志文件中，不会在日志文件中分割
log_bin_index 系统变量：查看二进制日志文件索引文件位置
sql_log_bin 会话变量：可以在会话级关闭二进制日志生成
验证二进制日志完整性：
默认情况下，MySQL Server 会写events和events长度用于验证events是否正确写入
如果 binlog_checksum 系统变量启用，MySQL Server 还会写入events校验和
这样在从二进制日志读信息时，Master Server会使用events长度，以及校验和信息（如果配置了master_verify_checksum 系统变量）
在Slave Server端，IO线程会验证从Master Server端接收的events，如果Slave Server端配置了slave_sql_verify_checksum 系统变量，Slave Server的SQL线程也会验证校验和信息
在二进制日志中记录的events的格式取决于二进制日志的格式，二进制日志格式包括：STATEMENT、ROW、MIX-BASED
可以通过 RESET MASTER命令删除所有的二进制日志，或者通过 PURGE BINARY LOG语句删除部分二进制日志
补充说明一下：
在复制环境中，在Master Server端，RESET MASTER不仅会删除所有的二进制日志，如果使用的是基于GTID复制模式，也会清除所有的GTID信息；在Slave Server端，RESET SLAVE删除所有中继日志，RESET SLAVE ALL不仅会删除所有中继日志，而且会清除连接、状态信息，在MySQL 8 中，默认使用mysql.slave_relay_log_info、mysql.slave_master_info表存储有关信息
可以通过mysqlbinlog命令查看二进制日志内容，这是MySQL Server做时间点恢复会有用，比如：
shell> mysqlbinlog log_file | mysql -h server_name
对于事务表，在语句或者事务完成后，释放锁或者提交前，会立即记录在二进制日志中
对于非事务表，在语句执行后，就会立即记录在二进制日志中
在一个未提交的事务中，所有对支持事务表的更改，在Server未接收到提交之前会先进行缓存；提交后，在执行COMMIT前，MySQL Server将整个事务写到二进制日志中
当一个线程开始处理事务时，会分配一个binlog_cache_size 系统变量的buffer用于buffer事务语句，如果事务语句大于binlog_cache_size 指定的值，线程打开一个临时文件用于存储该事务
binlog_cache_use 状态变量：查看MySQL Server中使用binlog_cache这个buffer的事务数量（包括使用临时文件的事务）
binlog_cache_disk_use 状态变量：查看MySQL Server中使用临时文件的事务
通过这两个状态变量，可以来调整binlog_cache_size值
MySQL Server中还定义了一个系统变量 max_binlog_cache_size用来限制整个Server中所有线程能够使用的binlog buffer 大小
基于ROW格式的二进制日志，对于像CREATE ... SELECT 和 INSERT ... SELECT语句会将其转化为一般的INSERT语句，这对于binlog_cache_size有一定的影响
binlog_error_action 系统变量：控制在写、刷新、同步二进制日志时发生错误，MySQL Server所采取的动作，默认是：ABORT_SERVER，另外一个值是：IGNORE_ERROR，这个值用于向后兼容
sync_binlog 系统变量：控制通过二进制日志的频率，默认值 1，是最安全的，但也是最慢的，与其相关的另一个系统变量：innodb_flush_log_at_trx_commit，默认值也是 1
早期MySQL Server存在的一种情况：
使用InnoDB表，MySQL处理事务，在将事务写到二进制日志后，提交事务到InnoDB前，系统崩溃，重启后，InnoDB回滚该事务，但是事务相关的日志保留在二进制日志文件中
早期解决这种情况的方法是使用XA事务，使InnoDB支持事务的两阶段提交，MySQL Server会截断二进制日志到最后有效的位置
在MySQL 8.0以后总是启用XA事务的两阶段提交，保证InnoDB 表数据与二进制日志数据一致
如果MySQL Server在崩溃恢复时发现二进制日志比他应该的大小下的时候，它丢失了至少一个成功提交的事务；在这种情况下，二进制日志是不正确的，复制应该从Master Server 新的快照中开始；
这种情况不会发生，如果sync_binlog=1并且二进制日志真的同步到磁盘上（有时不会）
sync_binlog=1: Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.
二进制日志格式：
binlog_format 系统变量：可选值：STATEMENT、ROW、MIXED
基于MIXED的二进制日志格式默认使用基于STATEMENT二进制日志格式
在复制模式下，主从节点的binglog_format应该保持一致
在使用InnoDB存储引擎，同时事务隔离等级时READ-COMMITTED情况下，将BINLOG_FORMAT设置为STATEMENT，会导致InnoDB表不能插入数据
binlog_row_event_max_size 系统变量：
Where possible, rows stored in the binary log are grouped into events with a size not exceeding the value of this setting. If an event cannot be split, the maximum size can be exceeded.