共计 1947 个字符，预计需要花费 5 分钟才能阅读完成。
错误日志
错误日志不用多说，记录了 MySQL 运行过程中的错误信息，当出现问题时，我们可以通过错误日志查找线索。
慢查询日志
可以通过参数 long_query_time 来设置时间，当 sql 语句执行超过指定的时间，就会被记录下来，用来进行 sql 调优。
还有一个参数 log_queries_not_using_indexs，如果运行的 sql 语句没有使用索引，就会记录下来。但是不能一直这样记录，会导致文件过大，索引可以通过 log_throttle_queries_not_using_indexes 来表示每分钟允许记录到 slow log 的未使用索引的 SQL 语句的次数。默认为 0，表示没有限制。如果日志记录到文件中，可以使用 mysqldumpslow 命令来进行筛选。
慢查询日志可以输出到文件中，也可以输出到表中。可以通过 log_output 参数指定慢查询日志输出到哪里。
在慢查询日志中都记录了什么信息，可以通过 slow_query_type 进行控制。
0 表示不将 SQL 语句记录到 slow log。
1 表示根据运行时间将 SQL 语句记录到 slow log。
2 表示根据逻辑 IO 次数将 SQL 语句记录到 slow log。
3 表示根据运行时间和逻辑 IO 次数将 SQL 语句记录到 slow log。
binlog 日志
记录了对数据库除了查询的所有操作。可以用来数据恢复、主从复制和判断数据库是否被攻击审计。
sync_binlog 参数
binlog 日志并不是每次写的时候都同步到磁盘。因此当数据库发生宕机的时候，可能会有一部分数据没有日志中。会跟复制和恢复带来问题。sync_binlog 表示每写缓冲多少次就同步到磁盘。如果设置位 1 即表示每写一次缓冲就把数据同步到磁盘。但是仍然存在问题，如果事务刚刚把数据写入日志，但是还没有执行的情况下宕机。数据库重启后会进行回滚，但是写入 binlog 的日志不能回滚。可以通过 innodb_support_xa= 1 来解决这个问题。
binlog_format 参数
该参数可以设置的值有 STATEMENT、ROW、MIXED。
1、STATEMENT 格式的日志，只记录 sql 语句
2、ROW 格式的日志，不是记录 SQL 语句，而是记录记录表的行更改情况。
3、MIXED 格式的日志，根据情况决定使用 STATEMENT 还是 ROW 格式记录日志。
MySQL 数据库的事务格式离别为 REPEATABLE READ，跟 binlog_format 是有关系的，如果设置为 READ COMMITED 的事务隔离级别，会出现类似丢失更新的现象，从而出现主动数据不一致。如果 binlog_format 采用的是 ROW 格式的记录，就可以将事务隔离级别调整为 READ COMMITED 来提高性能。
查询日志
记录所有的对数据库的请求，一般不开启。
重做日志
该日志文件属于 Innodb 存储引擎，记录了 Innodb 存储引擎的食物日志，直观重要。当执行事务失败时，该日志就能派上用场。
每个 Innodb 存储引擎至少有两个日志文件组，每个文件组下面至少有两个重做日志。
参数
Innodb_log-file_size
表示每个重做日志的大小。
Innodb_log_files_in_group
表示每个日志文件组有几个日志，最少有两个，默认为 2 个。
Innodb_mirrored_log_groups
镜像，为了高可用设计。如果进行了磁盘阵列，可以不设置。
Innodb_log_group_home_dir
日志文件存放的位置，默认为”./”。
Innodb_flush_log_at_trx_commit
当值为 0 时，代表当提交事务时，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新。
当值为 1 时，表示执行 commit 时将重做日志缓冲同步写到磁盘，即伴有 fsync 的调用。当事务提交时，必须保证事务已经写入重做日志文件。当数据库宕机时，可以通过重做日志文件恢复，并保证可以恢复已经提交的事务。
当值为 2 时，表示将重做日志异步写到磁盘。即写到文件系统的缓存中。因此不能完全保证执行 commit 时肯定会写入重做日志文件，知识有这个动作。当数据库宕机而服务器并没有宕机的情况下，因为此时未写入磁盘的事务保存在文件系统缓存中，当恢复时同样保证数据不丢失。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-08/146217.htm
