MySQL各类文件详解

一、参数文件

MySQL实例启动时，MySQL会先去读一个配置参数文件，用来寻找数据库的各种所在位置以及指定某些初始化参数，这些参数通常定义了某种内存结构有多大等设置。默认情况下，MySQL实例会按照一定的次序去取，你只需通过命令mysql –help | grep my.cnf来寻找即可。

MySQL实例也可以不需要参数文件，这时所有的参数值都取决于编译MySQL时指定的默认值和源代码中指定参数的默认值。但是，如果MySQL在默认的数据库目录下找不到mysql架构，则启动同样会失败，因为mysql架构中记录了访问该实例的权限，当找不到这个结构时，MySQL实例不会成功启动，你可以在错误日志中查看错误信息。

和Oracle参数文件不同的是，Oracle的参数文件分为二进制的参数文件和文件类型的参数文件，而MySQL的参数文件仅是文本的，方便的是，你可以通过编辑软件进行参数的编辑。那么什么是参数呢？简单地说，就是一个键值对，也就是MySQL中的变量；可以通过show variables查看所有的变量（参数）。都是到变量不是永久生效的（MySQL变量分为会话变量和全局变量），只有把变量当做参数定义到MySQL的文本文件中去才能永久生效。

Oracle的参数有所谓的隐藏参数，以供Oracle内部人士使用，SQL Server也有类似的参数，但是在MySQL没有，也不需要。即使Oracle和SQL Server中都有些所谓的隐藏参数，在绝大多数情况下，这些数据库厂商也不建议你在生产环境中对其进行很大的调整。

二、套接字文件

前面提到过，Unix系统下本地连接MySQL可以采用Unix域套接字方式，这种方式需要一个套接字（socket）文件。套接字文件可由变量socket控制。一般在/tmp目录下，名为mysql.sock。

三、PID文件

当MySQL实例启动时，会将自己的进程ID写入一个文件中，该文件即为pid文件。该文件可由变量pid_file控制。默认路径位于数据库目录下，文件名为主机名.pid。

四、日志文件

MySQL日志记录了MySQL数据库日常操作和错误信息。MySQL有不同类型的日志文件，各自存储了不同类型的日志，主要包含：错误日志、查询日志、慢查询日志、事务日志、二进制日志。从日志当中可以查询到MySQL数据库的运行情况、用户操作、错误信息等。可以为MySQL管理和优化提供必要的信息。对于MySQL的管理工作而言，这些日志文件是不可缺少的。下面将介绍MySQL各类日志的作用以及日志的管理。

• 错误日志（查看错误日志变量）

默认启用，错误日志记录MySQL服务器启动和关闭过程中的信息，服务器运行过程中的错误信息，事件调度器运行一个事件时产生的信息，以及在从服务器上启动从服务器进程时产生的信息。该日志文件默认存放在数据目录下，以主机名命名。如localhost.err。

• 查询日志（查看查询日志变量）

默认关闭，通用查询日志记录了所有对MySQL数据库请求的信息，无论这些请求是否得到了正确的执行。默认文件名为：主机名.log。从MySQL 5.1开始可以将查询日志的记录放入mysql架构下的general_log表中，默认是文件中存储。

• 慢查询日志（看慢查询日志变量）

MySQL慢查询日记用于记录SQL语句查询时间大于MySQL变量中定义的时间，以及可以选择定义记录没有使用索引的SQL查询语句。DBA可以通过慢查询日志来找出有问题的SQL语句，对其进行优化。MySQL慢查询日志默认关闭状态，所以需要通过参数slow_query_log=1开启慢查询日志，并通过long_query_time参数定义慢查询日志的阈值才可开始使用慢查询日志的功能，另外还可以加log-queries-not-using-indexes参数，表示未使用索引的查询也被记录到慢查询日志中，三个参数都可以动态开启。

慢查询日志中给出了账号、主机、运行时间、锁定时间、返回行等信息，然后根据这些信息来分析此SQL语句哪里出了问题。当开始使用慢查询功能后可能随着慢查询日志的越来越大，分析起来就不是那么容易了，这个时候就可以使用MySQL内置的mysqldumpslow命令来进行分析。

可以先使用sleep函数模拟一个慢查询语句，如下：

然后再使用mysqldumpslow来分析慢查询

慢查询日志记录方式默认是在文件中，从MySQL5.1开始支持记录到表中，这使得用户的查询更加方便和直观，如果想使用表需要管理员定义log_output参数。另外，同一般查询日志一样，慢查询日志可以直接删除。删除后在不重启服务器的情况下，需要执行flush logs语句重建日志文件。

PS：详情看使用mysqldumpslow工具分析MySQL慢查询

• 二进制日志（看二进制日志变量）

默认启用，通过参数log_bin定义，二进制日志主要记录任何或可能引起数据库变化的操作，二进制日志以一种有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息，是MySQL中非常重要的一个日志类型。它是MySQL用于复制和及时点还原一个重要的功能，但同时开启二进制日志记录功能会使MySQL性能下降1%。二进制日志文件的文件格式为二进制，不能像错误日志文件那样可以使用cat等命令查看，必须通过MySQL提供的工具mysqlbinlog处理。

1. 二进制日志记录格式

通过变量binlog_format可以修改和查看二进制日志记录格式，有以下三种。

1）基于语句（statement）：就是在二进制日志文件中记录SQL语句。基于语句的记录会带来一个问题就是如果Master中有使用如rand、uuid、date等函数，或者有使用触发器等可能会导致主从服务器上的表的数据不一致，这可能使得复制变得没有意义。

2）基于行（row）：在ROW格式下，二进制日志记录的不再是简单的SQL语句了，而是记录表的行更改情况。基于ROW格式的复制类似于Oracle的物理Standby。同时，对于上述提及的statement格式下复制的问题给予了解决。从MySQL5.1开始支持行记录。另外如果设置了bin_format为ROW，你可以将InnoDB的事务隔离级别设为READ COMMITTED，以获得更好的并发性。

3）混合模式（mixed）：默认采用基于statement的复制， 但是有一些情况下会使用ROW格式，可能的情况有：一是表的存储引擎为NDB，这时对于表的DML操作都会以ROW格式记录。二是使用了UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数；三是使用INSERT DELAY语句；四是使用用户定义函数；五是使用了临时表。

2. 二进制日志作用

1）即时点还原：某些数据的恢复需要二进制日志，例如，在一个数据库全备文件恢复后，用户可以通过二进制日志进行即时点还原数据。

2）复制：其原理跟恢复类似，通过复制和执行二进制日志使一台远程的MySQL数据库与一台数据库进行实时同步。

3）审计：用户可以通过二进制日志的信息来进行审计，判断是否有对数据库进行注入的攻击。

3. 二进制日志文件

当MySQL创建二进制日志文件时，首先创建一个以“filename”为名称，以“index”为后缀的文件，称之为二进制日志索引文件，如“mySQL-bin.index”；再创建一个以“filename”为名称，以“.000001”为后缀的文件，称之为二进制日志文件，如“mySQL-bin.00001”；它们默认都在数据目录下。当MySQL服务重新启动一次，二进制日志文件就会增加一个，并且后缀“.000001”就会加1递增，但所有的这些二进制日志文件都会记录到索引文件中去。如果日志长度超过了max_binlog_size定义的上线（默认是1GB）也会创建一个新的日志文件，也可以手动使用flush logs命令滚动日志文件。

4. 删除二进制文件

MySQL的二进制文件可以配置自动删除，同时MySQL也提供了安全的手动删除二进制文件的方法：RESET MASTER删除所有的二进制日志文件，新的日志文件扩展名将重新从000001开始编号；PURGE MASTER LOGS只删除部分二进制日志文件。

5. 暂停二进制文件

如果在MySQL的配置文件启动了二进制日志记录，MySQL会一直记录二进制日志。修改配置文件，可以停止二进制日志，但是需要重启MySQL数据库。MySQL提供了暂时停止二进制日志的功能。通过SET SQL_LOG_BIN语句可以使用MySQL暂停或者启动二进制日志。语法如下：

6. mysqlbinlog工具处理二进制日志文件

6.1 STATEMENT格式的日志

二进制日志文件的文件格式为二进制，不像错误日志文件，慢查询日志文件那样用cat、head等命令来查看。想要查看二进制日志文件的内容，须通过MySQL提供的工具mysqlbinlog。对于STATEMENT格式的二进制日志文件，使用mysqlbinlog后，就可以看到执行的逻辑SQL语句，其使用方式如下：

基于STATEMENT的二进制文件格式

第一行at指明了该事件在binlog文件中的位置。

第二行描述了事件：事件发生的日期和时间、服务器ID、事务的结束位置、事件的位置、原服务器生成此事件时的线程ID、语句的时间戳和写入二进制日志文件的时间差、错误代码。

第三行给出了该事件锁执行的SQL语句。

第四行描述了事件的结束位置，相当于下一事件的开始位置。

6.2 对于ROW格式的日志

如果使用ROW格式的记录方式，则会发现mysqlbinlog的结果变得不可读了，我们看不到指定的SQL语句，反而是一大串我们看不懂的字符。其实只要加上参数-v或-vv（显示数据类型等信息），就能清楚地看到执行的具体信息了，mysqlbinlog会向我们解释了具体做的事情，比如更新一条语句会记录整个行更改的信息。使用方法如下：

可以看出跟STATEMENT类型差异很大，ROW记录的是真正的数据信息，改变之前和改变之后的数据。

如果想显示具体执行的语句，可以在配置文件添加binlog-rows-query-log-events=on参数，这样就会显示具体的逻辑执行语句了，但是有注释。具体显示结果如下。

7. 二进制文件操作

• 中继日志

在MySQL中做主从复制时，从服务器会从主服务器复制主服务器的二进制日志文件中产生的事件，然后从服务器会把复制来的事件保存到自己的一个名为中继日志的文件中，最后重放此中继日志文件达到数据复制的目的。

• 事务日志

用于保证事务的可靠性，在进行事务操作时先写进事务日志而事务日志会记录老数据和新数据从而实现回滚。并且不用每次都将修改的数据本身持久到磁盘。事务日志采用的事追加的方式。因此写日志的操作时磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头。所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回磁盘。目前大多数存储引擎都是这样设计的。我们通常称之为预写式日志，修改数据需要写两次磁盘。

如果数据的修改意见记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体的恢复方式视存储引擎而定。

五、日志文件相关变量

在MySQL 5.7.2之后，如果设置了慢日志是写到文件里，需要设置log_timestamps（默认是UTC时间，比我们晚8小时，需要设置为系统时间log_timestamps=SYSTEM）来控制写入到慢日志文件里面的时区（该参数同时影响general日志和error日志）。如果设置慢日志是写入到数据库中，该参数将不产生作用。

如果需要查询所有全局日志的变量及参数，可以使用SHOW语句。

GLOBAL表示查全局系统变量的状态值（大概有61变量左右）。

• 错误日志

log_error = /var/log/mysqld.log

错误日志的存放位置，MySQL 5.5在数据目录下，MySQL 5.6在/var/log/mysql.log文件

log_warnings = 1

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

• 通用日志

general_log = OFF

一般查询日志，默认关闭，在启动mysqld时可以使用了–general_log选项开启一般查询。如若启用此项，其输出位置则由–log_output选项进行定义，如果log_output的值设定为NONE，即使用启用查询日志，其也不会记录任何日志信息。作用范围为全局，可用于配置文件，属动态变量

general_log_file = FILE_NAME

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

log = YES

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

• 慢查询日志

slow_query_log = OFF

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

log_output = FILE|TABLE|NONE

定义日志输出方式，默认是FILE。作用于查询日志和慢查询日志，属于动态变量可在线修改。如果改为TABLE存放，那么会在mysql架构的产生一个general_log和slow_log的表，此表默认使用的是CSV引擎。最好可以将次引擎改为MyISAM，但是必须在关闭慢查询之后才可修改。

slow_query_log_file = / PATH/TO/localhost-slow.log

设定文件格式的慢查询日志的存储路径。

long_query_time = 10.000000

设定区别慢查询与一般查询的语句执行时间长度，这里的语句执行时长为实际的执行时间，而非在CPU上的执行时长，因此，负载较重的服务器上更容易产生慢查询。其最小值为0，默认值为10秒，这里要注意的是，MySQL只记录大于10秒的SQL查询而等于或小于10秒的则不会记录。一条SQL语句运行0.5秒和0.05秒是非常不同的，前者可能已经进行了表扫，后者可能是走了索引。它也支持微秒级的解析度。作用范围为全局或会话级别，可用于配置文件，属动态变量。

log_queries_not_using_indexes = OFF

默认值为OFF，这个参数默认为OFF，当开启后，如果运行的SQL语句没有使用索引，则MySQL数据库同样会将这条SQL语句记录到慢查询日志文件中。MySQL 5.6新增变量。

log_throttle_queries_not_using_indexes = 0

默认值为0，这是MySQL 5.6.5版本开始新增的一个变量，用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数。该值默认为0，表示没有限制。这个参数是防止生产环境下没有使用索引的SQL语句过多而导致慢查询日志过大的问题。

min_examined_row_limit = 0

默认值为0，当查询语句扫描的行小于该参数指定值时不记录慢查询日志，需要开启log_queries_not_using_indexes=on时才会生效。怎么理解呢？开启log_queries_not_using_indexes参数时，意味着没有使用索引的语句都会记录慢查询日志，但有些语句有情况下是没有必要记录。比如，我们做的一些监控，查询元数据信息或视图时，又或者表数据过小时，就算没有使用索引，全表扫描的数据也不多；这种情况下就可以设置min_examined_row_limit参数，扫描行数小于这个值的就不记录慢查询日志了。

log_slow_admin_statements = OFF

默认值为OFF，这个变量是在MySQL 5.6.11中加入的，开启此选项后，当表管理语句，如更改表、分析表、表、创建索引、降索引、优化表和维护表执行时间大于等于long_query_time参数值时也会记录慢查询日志。作用范围为全局变量，可用于配置文件，属于动态变量。

log_slow_slave_statements = OFF

默认值为OFF，这个变量是在MySQL 5.6.11中加入的，当慢查询日志开启的时候，这个变量的开启可以设定从库记录主库超过long_query_time时间的查询日志。作用范围为全局变量，可用于配置文件，属于动态变量。

• 二进制日志

expire_logs_days = 0

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

binlog-format = {ROW|STATEMENT|MIXED}

这个参数影响了记录二进制日志的格式，值有ROW、STATEMENT、MIXED这三种。MySQL 5.5默认为MIXED混杂模式（就是平时使用statement记录二进制日志，但是需要使用ROW时就会使用）。这个参数对于binlog和复制的影响至关重要，生成环境基本都设置为ROW格式。

log_slave_updates = OFF

默认值为OFF，用于设定复制场景中的从服务器是否将从主服务器收到的更新操作记录进本机的二进制日志中，本参数设定的生效需要在从服务器上启用二进制日志功能。默认不会将从master取得并执行的二进制日志写入自己的二进制日志文件中。

log_bin = ON

默认为ON，启用二进制日志记录功能。作用范围为全局级别，属于静态变量。

sql_log_bin = ON

默认值为ON，用于控制二进制日志信息是否记录进日志文件，前提要开启二进制日志功能。作用范围为会话变量，属于动态变量。

max_binlog_size = 1073741824

默认为1G，指定单个二进制日志文件的最大值，如果超过该值，则产生新的二进制文件，后缀名+1，并记录到.index文件中。默认为1G，也可以手动刷新该文件。

sync_binlog = 0

默认值为0，在默认情况下，二进制日志并不是在每次写的时候同步到磁盘，它会进行缓冲写。因此，当数据库所在操作系统发生宕机时，可能会有最后一部分数据没有写入二进制日志文件中。此参数表示每次缓冲多少次就同步到磁盘，1表示采用同步写磁盘的方式来写二进制日志，这时写操作不适用操作系统的缓冲来写二进制日志，会带来一定的性能下降。该值默认为0，表示采取缓冲写，性能好。

但是，将sync_binlog设为1时，又有一种情况会导致问题的发生。当使用InnoDB存储引擎时，在一个事务发出COMMIT动作之前，由于sync_binlog设为1，因此会讲二进制日志立即写入磁盘。如果这个时候已经写入了二进制日志，但是提交还没有发生，并且此时发送了宕机，那么在MySQL数据库下次启动时，因为COMMIT操作并没有发生，所以这个事物会被回滚掉。但是二进制日志以及记录了该事物信息，不能被回滚。这个问题可以通过参数innodb_support_xa设为1来解决，虽然innodb_support_xa与XA事务有关，但它同时也确保了二进制日志和innodb存储引擎数据文件的同步。

log_bin_trust_function_creators = OFF

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

binlog_cache_size = 32768

默认为32k，当使用事务引擎时，所有未提交的二进制日志会被记录到一个缓存中去，而该缓冲的大小有此参数控制。此值不能设置过大，当然也不能过小，不然当一个事务的记录大于设定的binglog_cahce_size时，MySQL会把缓冲中的日志写入一个临时文件中。通过SHOW GLOBAL STATUS命令查看binlog_cache_use（记录使用缓冲写二进制日志的次数）、binglog_cahce_disk_use（记录使用临时文件写二进制日志的次数）的状态，可以判断当前binlog_cache_size的设置是否适合。

max_binlog_cache_size = 18446744073709547520

二进制日志语句缓存大小，字节为单位。表示的是binlog能够使用的最大cache内存大小。当我们执行多语句事务的时候所有的会话的使用的内存超过max_binlog_cache_size的值时。就会报错：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes ofstorage”。此值的大小跟内存中数据同步到磁盘上的时间有关，缓存越大性能越好数据丢失比例越大，缓存越小性能越低数据丢失比例越小。

binlog_stmt_cache_size = 32768

默认值32k，这个变量决定举行非事务语句在事务期间发布的二进制日志缓存的大小。如果服务器支持任何事务存储引擎，如果服务器有二进制日志启用，则为每个客户端分配一个单独的二进制日志事务和语句缓存。如果你经常使用大型非事务语句在交易过程中，你可以增加缓存大小以获得更好的性能。可以通过查状态变量binlog_stmt_cache_use和binlog_stmt_cache_disk_use的值来判断32k是否够用。

max_binlog_stmt_cache_size = 18446744073709547520

如果非事务语句在事务需要超过多少字节的内存，服务器会生成一个错误。

binlog_rows_query_log_events = OFF

MySQL 5.7新增参数，默认关闭 ，可选打开，建议打开，还是比较有用的。可以看到二进制日志格式为row的情况下的sql语句，方便排查问题和恢复数据。

binlog_max_flush_queue_time = 0

默认值为0，用来控制MySQL 5.6新增的BLGC（binary log group commit），就是二进制日志组提交中Flush阶段中等待的时间，即使之前的一组事务完成提交，当前一组的事务也不马上进入Sync阶段，而是至少需要等待一段时间，这样做的好处是group commit的事务数量更多，然而这也可能会导致事务的响应时间变慢。该参数默认为0表示不等待，且推荐设置依然为0。除非用户的MySQL数据库系统中有大量的连接（如100个连接），并且不断地在进行事务的写入或更新操作。（注：binlog_max_flush_queue_time在MySQL的5.7.9及之后版本不再生效）

binlog_group_commit_sync_delay = 0

binlog_group_commit_sync_no_delay_count = 0

MySQL 5.7.9版本后，binlog_max_flush_queue_time参数失效。新增的两个参数，表示一次组提交等待binlog_group_commit_sync_delay延迟多少毫秒直到达到binlog_group_commit_sync_no_delay_count事务个数时，将进行一次组提交。当达到binlog_group_commit_sync_delay参数值时，就算没有满足binlog_group_commit_sync_no_delay_count值，也会进行组提交，此参数最大值为1s。也是为了减少磁盘sync动作，增加性能。另外MySQL 5.7多线程复制也是基于组提交，所以一次组提交中的事务越多，复制性能越好。

• 中继日志

relay_log = relay-bin

开启中继日志，这里的值时中继日志的基名。默认是库的名字是host_name-realy-bin，服务器在数据目录中写入文件，除非给出了一个具有领先绝对路径的文件制定一个不同的目录。服务器通过在基名中添加一个数字后缀来创建中继日志文件。

relay_log_index = relay-bin.index

用于中继日志索引文件的名称，默认名称是在数据目录host_name-relay-bin.index，哪里host_name是从服务器的名称。

relay_log_info_file = relay.info

该文件用于记录中继日志的文件和事件位置以及二进制的文件和事件位置，当relay_log_info_repository=FILE时有效。

relay_log_info_repository = FILE|TABLE

这个变量决定从库IO线程接收到的中继日志position点是写入到一个文件还是表（MySQL.slave_relay_log_info）。

sync_relay_log_info = 10000

这个变量用来配置从库relay log接收多少个event会刷新relay.info文件，当relay_log_info_repository=FILE时有效。默认为10000，为0则表示不刷新，交由OS的cache控制，系统默认1s刷新一次。

sync_relay_log = 10000

这个参数和sync_binlog是一样的，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值默认是0，可动态修改，建议采用默认值。

master_info_repository = FILE|TABLE

这个变量决定从库SQL线程执行relay log的position点是写入到一个文件还是表（MySQL.slave_master_info）。

sync_master_info = 10000

这个变量用来配置从库SQL线程执行多少个event会刷新master.info文件，当master_info_repository=FILE时有效。默认为10000，为0则表示不刷新，交由OS的cache控制，系统默认1s刷新一次。

relay_log_purge = ON

默认值为ON，启动自动清理已经应用过的中继日志。这是一个全局变量。

relay_log_recovery = OFF

默认值为OFF，当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log。根据SQL线程执行binlog position开始重新从master上获取binlog日志，这样就保证了从库的安全性（前提是从库master.info记录为TABLE时才有效）。默认情况下该功能是关闭的，将relay_log_recovery的值设置为1时，可在slave从库上开启该功能，建议开启。

relay_log_space_limit = 0

防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用。

max_relay_log_size = 0

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

八、总结

日志对于性能调优，故障排查无疑是非常重要的，但也会影响MySQL的性能，又会占用大量磁盘空间。因此，如果不必要，应尽可能少地开启日志。根据不同的使用环境，可以考虑开启不同的日志。例如，在开发环境中优化查询效率低的语句，可以开启慢查询日志；如果需要记录用户的所有查询操作，可以开启通用查询日志；如果需要记录数据的变更，可以开启二进制日志；错误日志时默认开启的。

喜欢 (1)赏

[资助本站您就扫码 谢谢]

分享 (0)