Fork me on GitHub
Fork me on GitHub

MySQL日志功能详解

发表于   |   更新于   |   分类于   |   阅读次数

MySQL日志

  1. 查询日志
    这是最不应该记录的日志。因为一个非常繁忙的数据库服务器，其查询会有很多，每一次都记录日志会导致系统性能下降。而且还会有额外的空间开销。MySQL默认没有开启这个日志。注意不仅仅是SELECT。

  2. 慢查询日志
    查询执行时长超过指定时长的查询，即为慢查询。这里的慢不一定是语句自身执行慢，如果一个操作锁定了某张表，尤其是独占锁锁定了这张表，那么其他人对于这张表的查询就阻塞掉了。但不管怎么讲，慢查询日志是我们通常拿来定位系统上查询操作执行速度过慢时常用到的一个评估工具。所以在生产环境中有时是很有必要启用慢查日志的。percona公司在提供的工具perconatools中有专门工具用来分析慢查日志中哪些查询执行时长过长，以及产生的原因有哪些。这是一个应该启用的日志，但是默认没启用。

  3. 错误日志
    通常情况下记录的不光是错误信息，也包括mysql启动和关闭过程中的信息，以及启动复制线程时的信息。

  4. 中继日志
    在从服务器上的日志。就是说复制的时候，主服务器任何能够产生数据修改的操作，在写入数据文件的同时，还会把这个语句(也可能是行)记录到二进制日志文件中一份。从服务器就是使用一个用户帐号不断的去连接主服务器，并尝试去读取主服务器上二进制日志中的每一个条目，从服务器将这些挨个的读到从服务器上，在执行之前，先要将这些读到的保存在本地的日志文件中，而后从本地日志文件中读一条执行一条。这个日志文件就叫做中继日志。很显然，中继日志内容应该和二进制日志内容是一样的，为了完成复制，二进制日志不能随便删除，中继日志可以删除，用完后清了。如果发现清错了，可以找个二进制日志复制下就可以了。再想一个问题，从服务器也有二进制日志，每次执行都是从中继日志中读，然后执行，同时还要写入二进制日志，如果要记录二进制日志的话，应该是和主服务器的二进制日志一样的。这种记录是额外的开销，如果其他服务器不把这个从服务器当做主来用，这个二进制日志就没有用了，所以应该关闭掉，以提升性能。另外，从服务器是不能执行额外的任何写操作的，只能从中继日志中读一条写一条。

  5. 事务日志
    先暂存事务提交的数据，然后在同步到数据文件中。
    随机I/O转换为顺序I/O。但是即便是顺序I/O，其速度依然有限。把事务日志放在RAID10上，或放在固态硬盘上，或放在PCI-E固态硬盘上，那就体会几乎内存的性能了。
    如果是支持事务的存储引擎，要满足事务的要求，就必须满足ACID测试，其中有一点很重要就是持久性。事务还要能够回滚。考虑一种场景，我们的事务隔离级别是”读未提交”，两个连接进来了，都在做事务，第一个事务执行的语句，它的事务在提交之前有可能是保存在内存中，有可能是被同步到事务日志中，内存中可能放不下，就放到事务日志中去了。当第二个事务查询时，它的查询应该是来自磁盘上的数据文件，但问题是第一个事务执行的操作还没有同步到磁盘上，那它怎么查到呢？所以要支持事务，背后的工作逻辑是很复杂的，不但要从数据文件中找，还要去找那些有可能潜在修改这个数据文件的数据集，比如内存缓冲区，这个缓冲区我们称为innodb_buffer，还有可能要去查询事务日志。所以事务日志还要支撑读操作。只有完全把buffer和事务日志中的数据全部同步到磁盘的数据文件中去了，从磁盘上读到的数据才是最新的。所以buffer和事务日志中所保存的数据接近于表中所存储的格式的。
    再考虑一种场景如果我们启动了一个非常大的事务，那么buffer实在缓存不下了，就要先写到事务日志中去了，日志文件至少需要两个，以实现轮替的，两个组成一个日志文件组。第一个日志文件写满了，就去写第二个。日志文件一个5M，可以调整的，但是大多数场景是够用的。第一个日志文件不够用了，写第二个日志文件，然后第一个日志文件中的数据开始往磁盘数据文件同步。即便如此，这个事务只执行了一半或者2/3，过一会，回滚。该怎么回滚？那些写到磁盘数据文件的数据也得删掉。所以回滚也是一个非常复杂的操作。如果说这个回滚的所有数据最多只到事务日志中和最多走到数据文件中，哪种回滚的开销比较小？只是走到事务日志中开销比较小，甚至于还没走到事务日志中，仍然还在innodb_buffer中，回滚的开销会更小，所以我们应该使用小事务。
    为了保证提交的事务不丢失，其一部分写操作可能在内存中，我们一commit，所有位于内存中的数据有可能会因为断电或系统崩溃而丢失，为了避免这种情况，要立即写到持久存储中去。写到事务日志中。假如一个事务提交了，刚从内存中同步到事务日志中，还没同步到数据文件中，系统崩溃了。下次启动时，这个事务能恢复回来，因为事务日志中有。所以下一次mysql启动时，它必须保证把那些提交的事务从事务文件中同步到数据文件中。而未提交的事务，比如有些事务正在操作，但并未提交，系统崩溃了，这种情况怎么办？因为没有完成，所以之前这个事务的操作全部回滚，这个过程就叫做系统崩溃恢复的过程。把那些提交的事务同步到数据文件中，没提交的事务回滚。而事务性存储引擎的崩溃恢复能力是天生的。
    如果MySQL崩溃是因为事务日志的磁盘坏了，这种情况下，就不能崩溃恢复了。只能用备份恢复了。所以我们应该让事务日志所在的硬盘足够可靠，RAID10或者RAID1。假如说是因为数据文件崩溃了，一样的场景。你有事务日志，但你数据文件坏了，怎么去写啊。有事务日志并不能恢复数据，事务日志不是用来恢复数据的，事务日志仅仅是崩溃时能够保证已提交事务不丢失，未提交事务能回滚。
    从性能上来讲，将事务日志和数据文件放在一块是不合理的。从内存到硬盘，I/O，从事务日志到数据文件也要I/O，所有的I/O都压在一块硬盘上去了，导致性能下降。因此，把数据文件放在一个RAID设备上，把事务日志放在一个RAID设备上。考虑独特的场景，我们实在没有RAID设备放事务日志了，那就给事务日志做镜像。如果你实在是没钱，那就找个其他磁盘空间，跟事务日志文件不在同一个磁盘上就行，做一个mirror，任何往第一组事务日志中写的数据会被自动同步到第二组中去的。
    日志文件组：至少应该有两个日志文件；
    【注意】：尽可能使用小事务以提升事务引擎的性能；

  6. 二进制日志
    主要用于MySQL时间点恢复和复制。

查询日志

  • log={ON|OFF}:是否记录所有语句的日志信息于一般查询日志文件(general_log)。MySQL5.6已经弃用此项变量了，都使用general_log。
  • log_output={TABLE|FILE|NONE}
    • TABLE：记录于表中。MySQL库中会自动生成一个表记录。
    • FILE：记录于general_log_file。
    • NONE：不记录。
    • TABLE和FILE可以同时出现，用逗号分隔即可。
  • general_log：是否启用查询日志。由于历史的原因，和log是个冲突的概念。
  • general_log_file：定义一般查询日志保存的文件。文件名为：主机名.log，保存路径没说的话保存在数据目录中。所有的相对路径通常都是相对于数据目录而言的。
1
mysql> SHOW GLOBAL VARIABLES LIKE "%log%";


如果开启查询日志，包括SHOW、SET操作也会被记录，这些操作过程中也需要查询。如果要记录查询日志，记录到数据库中，会比记录到文件中快一点。但是一般是不启用记录查询日志的，除非特殊情况。

慢查询日志

  • long_query_time： 10.000000
    执行多长时间的查询算是慢查询
  • slow_query_log={ON|OFF} 或者是1 | 0
    设定是否启用慢查询日志；它的输出位置也取决log_output={TABLE|FILE|NONE}；
  • slow_query_log_file=www-slow.log
    定义日志文件路径及名称；
  • log_slow_queries=ON
  • 与上面slow_query_log={ON|OFF}好像是重复的，上面那个是全局的，下面这个是用户自己会话的。
  • log_slow_rate_limit=1 记录慢查询日志的速率。
  • log_slow_verbosity 是否记录详细的慢查询的详细信息。
1
2
3
4
5
6
7
mysql> SHOW GLOBAL VARIABLES LIKE "long%";
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

错误日志

错误日志： 通常是开启的。

  • 服务器启动和关闭过程中的信息；
  • 服务器运行过程中的错误信息；
  • 事件调度器运行一个事件时产生的信息；

  • 在复制架构中的从服务器上启动从服务器线程时产生的信息。

  • log_error = /path/to/error_log_file

  • log_warnings = {1|0}
    是否记录警告信息于错误日志中。
1
2
3
4
mysql> SHOW GLOBAL VARIABLES LIKE "%log%";
...
| log_error                               | /data/mydata/db.err           |
...

二进制日志

二进制日志介绍

二进制日志：也称为复制日志，记录的是”修改”类信息，记录的是一个个事件。
格式也应该是二进制的，不能使用cat命令查看，有专门的工具mysqlbinlog可以查看。
二进制日志能够基于过去某个数据集的基础上，把后续的所有操作重新跑一遍，能得到和此前第一次跑时所得到的是一样的结果。日志文件名字以及存放路径都是可以定义的。比如我在安装mysql时将数据文件和二进制日志文件就定义在了不同的目录：

[root@db ~]# cd /data/binlog/
[root@db binlog]# ls
master-bin.000001  master-bin.000003  master-bin.000005  master-bin.000007  master-bin.index
master-bin.000002  master-bin.000004  master-bin.000006  master-bin.000008
[root@db binlog]# file master-bin.000001
master-bin.000001: MySQL replication log

可以使用工具mysqlbinlog查看二进制日志文件内容：

[root@db binlog]# mysqlbinlog master-bin.000001


这个事件从66773开始到66846结束，66846-66773=中间的信息的偏移量。

  • position：位置，空间记录法。空间记录法就是相对于当前日志文件而言它的偏移位置。
  • time: 时间点，时间记录法。

二进制日志文件内容格式：

  • 事件发生的日期和时间
  • 服务器ID
  • 事件的结束位置
  • 事件的类型
  • 原服务器生成此事件时的线程ID
  • 语句的时间戳和写入二进制日志文件的时间差。exec_time=0，由于单位是s，所以很多时候是0。
  • 错误代码；
  • 事件内容：也就是语句本身。
  • 事件位置，相当于下一事件的开始位置

考虑一种场景：如果说我们有多个进程同时进行，比如处理两个请求的两个线程分别在两颗CPU上跑着，而且修改不是同一张表，这个时候都需要写入二进制日志，但是某个时刻只会往一个二进制日志文件中写，具体哪个见下面的命令。显然，这个文件不能有两个进程同时写，如果交替着写，事件就混到一块了。由于二进制日志成为了资源争用点，有可能会导致性能下降，如果你去设计的话，如何去避免性能下降？缓存，于是每一个线程在写数据时不是直接写文件，而是写在缓冲区中，专业点的说法是，写通常是叫做缓冲。过一段时间，由MySQL服务器后台线程找空闲时间自行往二进制日志文件中同步。但这会带来一个问题，如果说事件写在缓冲区中了，忽然间系统断电了，这些缓冲区的数据还没写到二进制文件中去呢，那么拿来二进制日志执行，数据也不对。虽然没有写到二进制日志文件中去，但是却已经写到本地数据文件中去了。只不过这个有可能产生数据修改的操作还得写到记录到二进制日志中去。将来把这个二进制日志信息复制到从服务器上，重新跑一遍，得到的数据不一样。因此这是不安全的做法。通常效率和安全性通常是两个背离的方向。所以我们要求应该在事务提交时无论如何也应该把二进制日志缓冲区中的信息同步到二进制日志文件中去。

滚动： 二进制日志文件需要不停的进行滚动，防止文件大小过大。
1、大小
2、时间

二进制日志的功用：

  1. 即时点恢复：我们想恢复到哪个位置，可以通过二进制日志文件手动调整进行的。
  2. 复制。

二进制日志常用命令

1.查看当前服务器所正在使用的二进制日志文件，以及下一个事件要开始时记录的位置

mysql> SHOW MASTER STATUS;
+-------------------+----------+--------------+------------------+-------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000008 |  5525554 |              |                  |                   |
+-------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

2.每一次重启MySQL服务器或者FLUSH LOGS，日志文件都会滚动。FLUSH LOGS，对错误日志等没有意义，它主要是用来滚动二进制日志和中继日志的。二进制日志不像事务日志ib_logfile0、ib_logfile1，反复被用到。

mysql> FLUSH LOGS;

3.查看有多少二进制日志文件及其大小

mysql> SHOW BINARY LOGS; 
+-------------------+-----------+
| Log_name          | File_size |
+-------------------+-----------+
| master-bin.000001 |     67251 |
| master-bin.000002 |   1361538 |
| master-bin.000003 |  73892389 |
| master-bin.000004 |       120 |
| master-bin.000005 |   5076873 |
| master-bin.000006 |   8200661 |
| master-bin.000007 |  30885330 |
| master-bin.000008 |   5525554 |
+-------------------+-----------+
8 rows in set (0.00 sec)

我们可以通过删除文件的方式清除二进制日志，注意不到万不得已，千万不要手动删除。而且手动删除也不是通过删除文件删除的，而是通过PURGE命令删除的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
mysql> HELP PURGE
Name: 'PURGE BINARY LOGS'
Description:
Syntax:
PURGE { BINARY | MASTER } LOGS
    { TO 'log_name' | BEFORE datetime_expr }
The binary log is a set of files that contain information about data
modifications made by the MySQL server. The log consists of a set of
binary log files, plus an index file (see
http://dev.mysql.com/doc/refman/5.6/en/binary-log.html).
The PURGE BINARY LOGS statement deletes all the binary log files listed
in the log index file prior to the specified log file name or date.
BINARY and MASTER are synonyms. Deleted log files also are removed from
the list recorded in the index file, so that the given log file becomes
the first in the list.
This statement has no effect if the server was not started with the
--log-bin option to enable binary logging.
URL: http://dev.mysql.com/doc/refman/5.6/en/purge-binary-logs.html
Examples:
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

4.查看事件信息

1
2
3
4
5
6
7
8
9
10
11
mysql> HELP SHOW BINLOG EVENTS
Name: 'SHOW BINLOG EVENTS'
Description:
Syntax:
SHOW BINLOG EVENTS
   [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]
Shows the events in the binary log. If you do not specify 'log_name',
the first binary log is displayed.
URL: http://dev.mysql.com/doc/refman/5.6/en/show-binlog-events.html

mysql> SHOW BINLOG EVENTS IN 'master-bin.000001'\G

  • server-id: 服务器身份标识。MySQL的复制模型可以做的很复杂，服务器之间可以互为主从，也就是说各自是对方的主，又各自是对方的从。也就意味着左边的服务器也会复制右边的服务器的二进制日志，右边的机器是从左边的二进制日志中读取信息到中继日志中，并执行，同时写入自己的二进制日志，那左边从右边的二进制日志拿回来在执行一次，也就重复了。为了避免重复，server-id。左边读回来的信息发现是自己的server-id，就不会执行了。

或者可以使用mysqlbinlog工具查看事件信息：

# mysqlbinlog      
    --start-time
    --stop-time
    --start-position
    --stop-position

考虑一种场景：我们当前执行了INSERT INTO t1 VALUE (CURRENT_DATE())，记录到了二进制日志，但是以后拿这个日志跑一遍，很显然这个函数在那个时刻获得值肯定和现在不一样的。
MySQL记录二进制日志的格式的三种方式：

  • 基于语句：statement。像上面那个插入语句，就不能基于语句做了，就得把那个时间记录下来，叫基于行记录。
  • 基于行：row。但是基于行，每个行都得记录，比如我执行了一条语句UPDATE tb1 SET salary=salary+1000; ，如果公司有2万人，基于行记录得产生很大的数据量，但是基于语句，只需要记录这个语句就行。
  • 混合模式：mixed。由MySQL自动判断基于哪种方式记录。

二进制日志相关配置

跟二进制日志相关的服务器参数：
1.log_bin = {ON|OFF}, 是否开启二进制日志。还可以是个文件路径。同样二进制日志文件也不要和数据文件放在一起。建议在安装好MySQL就配置好二进制日志文件存放路径和没给你做。

[root@db ~]# vim /etc/my.cnf

2.log_bin_trust_function_creators：用于控制创建存储函数时如果会导致不完全事件的记录。一般是OFF。

3.sql_log_bin = {ON|OFF} sql_log_bin 是一个动态变量，修改该变量时，可以只对当前会话生效（Session），也可以是全局的（Global），当全局修改这个变量时，只会对新的会话生效（这意味当对当前会话也不会生效），因此一般全局修改了这个变量后，都要把原来的所有连接 kill 掉。在 mysql 启动时，通过命令行或配置文件决定是否开启 binlog，而 log_bin 这个变量仅仅是报告当前 binlog 系统的状态（打开与否）。若你想要关闭 binlog，你可以通过修改 sql_log_bin 并把原来的连接 kill 掉，也可以修改 log_bin，然后重启 mysql，后者更彻底，缺点就是需要重启。

4.sync_binlog：设定多久同步一次。就是定义多久将缓冲区中的二进制日志信息同步到二进制日志文件中。时间间隔越长，性能就越好，但数据安全性就越差。默认为0，表示不同步，也就是不靠时间来控制。如果你给的是正值，就表示每隔多长时间会同步。事实上如果你的auto_commit=0，意味着每一次事务提交时才会自动同步。虽然这里是二进制日志，和事务没关系，但为了保证事务安全，每一次事务提交时都会同步二进制日志。因此如果auto_commit=1，每个语句执行完都会同步，这是相当的性能低下。sync_binlog和MySQL的性能密切相关，虽然说不至于和事务日志、事务日志的刷写方式影响那么严重，这也是应该引起我们重视的一个服务器参数。=0反而是性能表现比较好的方式。默认情况下auto_commint=1，见下图。建议关闭。

5.binlog_format = {statement|row|mixed}

6.max_binlog_cache_size =
二进制日志缓冲空间大小，从MySQL5.5.9以后仅用于缓冲事务类的语句。一般不需要调整。如果是非事务类的，比如Aria存储引擎，max_binlog_stmt_cache_size。

7.max_binlog_stmt_cache_size =
非事务类的和事务类的共用的空间大小。一般不需要调整。

8.max_binlog_size =
二进制日志文件上限。一旦超过这个大小，就自动滚动了。默认单位是bytes。

建议：切勿将二进制日志与数据文件放在一同设备。MySQL的很多默认设定并不适合生产环境，我们需要调整。

中继日志：对于非从服务器，其中继日志默认是不启用的。

relay_log_purge={ON|OFF} 是否自动清理 不再需要的中继日志。

总结日志相关的服务器参数

  1. expire_logs_days={0..99}
    设定二进制日志的过期天数，超出此天数的二进制日志文件将被自动删除。默认为0，表示不启用过期自动删除功能。如果启用此功能，自动删除工作通常发生在MySQL启动时或FLUSH日志时。作用范围为全局，可用于配置文件，属动态变量。

  2. general_log={ON|OFF}
    设定是否启用查询日志，默认值为取决于在启动mysqld时是否使用了–general_log选项。如若启用此项，其输出位置则由–log_output选项进行定义，如果log_output的值设定为NONE，即使用启用查询日志，其也不会记录任何日志信息。作用范围为全局，可用于配置文件，属动态变量。

  3. general_log_file=FILE_NAME
    查询日志的日志文件名称，默认为“hostname.log”。作用范围为全局，可用于配置文件，属动态变量。

  1. binlog-format={ROW|STATEMENT|MIXED}
    指定二进制日志的类型，默认为STATEMENT。如果设定了二进制日志的格式，却没有启用二进制日志，则MySQL启动时会产生警告日志信息并记录于错误日志中。作用范围为全局或会话，可用于配置文件，且属于动态变量。

  2. log={YES|NO}
    是否启用记录所有语句的日志信息于一般查询日志(general query log)中，默认通常为OFF。MySQL 5.6已经弃用此选项。

  3. log-bin={YES|NO}
    是否启用二进制日志，如果为mysqld设定了–log-bin选项，则其值为ON，否则则为OFF。其仅用于显示是否启用了二进制日志，并不反应log-bin的设定值。作用范围为全局级别，属非动态变量。

  4. log_bin_trust_function_creators={TRUE|FALSE}
    此参数仅在启用二进制日志时有效，用于控制创建存储函数时如果会导致不安全的事件记录二进制日志条件下是否禁止创建存储函数。默认值为0，表示除非用户除了CREATE ROUTING或ALTER ROUTINE权限外还有SUPER权限，否则将禁止创建或修改存储函数，同时，还要求在创建函数时必需为之使用DETERMINISTIC属性，再不然就是附带READS SQL DATA或NO SQL属性。设置其值为1时则不启用这些限制。作用范围为全局级别，可用于配置文件，属动态变量。

  5. log_error=/PATH/TO/ERROR_LOG_FILENAME
    定义错误日志文件。作用范围为全局或会话级别，可用于配置文件，属非动态变量。

  6. log_output={TABLE|FILE|NONE}
    定义一般查询日志和慢查询日志的保存方式，可以是TABLE、FILE、NONE，也可以是TABLE及FILE的组合(用逗号隔开)，默认为TABLE。如果组合中出现了NONE，那么其它设定都将失效，同时，无论是否启用日志功能，也不会记录任何相关的日志信息。作用范围为全局级别，可用于配置文件，属动态变量。

  7. log_query_not_using_indexes={ON|OFF}
    设定是否将没有使用索引的查询操作记录到慢查询日志。作用范围为全局级别，可用于配置文件，属动态变量。

  8. log_slave_updates
    用于设定复制场景中的从服务器是否将从主服务器收到的更新操作记录进本机的二进制日志中。本参数设定的生效需要在从服务器上启用二进制日志功能。

  9. log_slow_queries={YES|NO}
    是否记录慢查询日志。慢查询是指查询的执行时间超出long_query_time参数所设定时长的事件。MySQL 5.6将此参数修改为了slow_query_log。作用范围为全局级别，可用于配置文件，属动态变量。

  10. log_warnings=#
    设定是否将警告信息记录进错误日志。默认设定为1，表示启用；可以将其设置为0以禁用；而其值为大于1的数值时表示将新发起连接时产生的“失败的连接”和“拒绝访问”类的错误信息也记录进错误日志。

  11. long_query_time=#
    设定区别慢查询与一般查询的语句执行时间长度。这里的语句执行时长为实际的执行时间，而非在CPU上的执行时长，因此，负载较重的服务器上更容易产生慢查询。其最小值为0，默认值为10，单位是秒钟。它也支持毫秒级的解析度。作用范围为全局或会话级别，可用于配置文件，属动态变量。

  12. max_binlog_cache_size{4096 .. 18446744073709547520}
    二进定日志缓存空间大小，5.5.9及以后的版本仅应用于事务缓存，其上限由max_binlog_stmt_cache_size决定。作用范围为全局级别，可用于配置文件，属动态变量。

  13. max_binlog_size={4096 .. 1073741824}
    设定二进制日志文件上限，单位为字节，最小值为4K，最大值为1G，默认为1G。某事务所产生的日志信息只能写入一个二进制日志文件，因此，实际上的二进制日志文件可能大于这个指定的上限。作用范围为全局级别，可用于配置文件，属动态变量。

  1. max_relay_log_size={4096..1073741824}
    设定从服务器上中继日志的体积上限，到达此限度时其会自动进行中继日志滚动。此参数值为0时，mysqld将使用max_binlog_size参数同时为二进制日志和中继日志设定日志文件体积上限。作用范围为全局级别，可用于配置文件，属动态变量。

  2. innodb_log_buffer_size={262144 .. 4294967295}
    设定InnoDB用于辅助完成日志文件写操作的日志缓冲区大小，单位是字节，默认为8MB。较大的事务可以借助于更大的日志缓冲区来避免在事务完成之前将日志缓冲区的数据写入日志文件，以减少I/O操作进而提升系统性能。因此，在有着较大事务的应用场景中，建议为此变量设定一个更大的值。作用范围为全局级别，可用于选项文件，属非动态变量。

  3. innodb_log_file_size={108576 .. 4294967295}
    设定日志组中每个日志文件的大小，单位是字节，默认值是5MB。较为明智的取值范围是从1MB到缓存池体积的1/n，其中n表示日志组中日志文件的个数。日志文件越大，在缓存池中需要执行的检查点刷写操作就越少，这意味着所需的I/O操作也就越少，然而这也会导致较慢的故障恢复速度。作用范围为全局级别，可用于选项文件，属非动态变量。

  4. innodb_log_files_in_group={2 .. 100}
    设定日志组中日志文件的个数。InnoDB以循环的方式使用这些日志文件。默认值为2。作用范围为全局级别，可用于选项文件，属非动态变量。

  5. innodb_log_group_home_dir=/PATH/TO/DIR
    设定InnoDB重做日志文件的存储目录。在缺省使用InnoDB日志相关的所有变量时，其默认会在数据目录中创建两个大小为5MB的名为ib_logfile0和ib_logfile1的日志文件。作用范围为全局级别，可用于选项文件，属非动态变量。

  6. relay_log=file_name
    设定中继日志的文件名称，默认为host_name-relay-bin。也可以使用绝对路径，以指定非数据目录来存储中继日志。作用范围为全局级别，可用于选项文件，属非动态变量。

  7. relay_log_index=file_name
    设定中继日志的索引文件名，默认为为数据目录中的host_name-relay-bin.index。作用范围为全局级别，可用于选项文件，属非动态变量。

  8. relay-log-info-file=file_name
    设定中继服务用于记录中继信息的文件，默认为数据目录中的relay-log.info。作用范围为全局级别，可用于选项文件，属非动态变量。

  9. relay_log_purge={ON|OFF}
    设定对不再需要的中继日志是否自动进行清理。默认值为ON。作用范围为全局级别，可用于选项文件，属动态变量。

  10. relay_log_space_limit=#
    设定用于存储所有中继日志文件的可用空间大小。默认为0，表示不限定。最大值取决于系统平台位数。作用范围为全局级别，可用于选项文件，属非动态变量。

  11. slow_query_log={ON|OFF}
    设定是否启用慢查询日志。0或OFF表示禁用，1或ON表示启用。日志信息的输出位置取决于log_output变量的定义，如果其值为NONE，则即便slow_query_log为ON，也不会记录任何慢查询信息。作用范围为全局级别，可用于选项文件，属动态变量。

  12. slow_query_log_file=/PATH/TO/SOMEFILE
    设定慢查询日志文件的名称。默认为hostname-slow.log，但可以通过–slow_query_log_file选项修改。作用范围为全局级别，可用于选项文件，属动态变量。

  13. sql_log_bin={ON|OFF}
    用于控制二进制日志信息是否记录进日志文件。默认为ON，表示启用记录功能。用户可以在会话级别修改此变量的值，但其必须具有SUPER权限。作用范围为全局和会话级别，属动态变量。

  14. sql_log_off={ON|OFF}
    用于控制是否禁止将一般查询日志类信息记录进查询日志文件。默认为OFF，表示不禁止记录功能。用户可以在会话级别修改此变量的值，但其必须具有SUPER权限。作用范围为全局和会话级别，属动态变量。

  15. sync_binlog=#
    设定多久同步一次二进制日志至磁盘文件中，0表示不同步，任何正数值都表示对二进制每多少次写操作之后同步一次。当autocommit的值为1时，每条语句的执行都会引起二进制日志同步，否则，每个事务的提交会引起二进制日志同步。