对付MySQL的一般查询日志和慢查询日志，开启较量简朴，个中公用的一个参数是log_output，log_output节制着慢查询和一般查询日志的输出偏向可以是表（mysql.general_log,mysql.slow_log）可能文件（有参数general_log_file和slow_query_log_file设置抉择）可能同时输出到表和文件（想不大白，什么时候需要同时输出到表和文件）。

可是两者受log_output参数影响，输出的方针老是一致的，也就是要么都写入表，可能要么都写入文件，不会一个输出到表，一个输出到文件。

--slow log 相关参数
select * 
from performance_schema.global_variables 
where variable_name in
('slow_query_log','log_output','slow_query_log_file','long_query_time')

--general log 相关参数
select * 
from performance_schema.global_variables 
where variable_name in
('general_log','log_output','general_log_file')

对付上述两种日志，系统默认不会清理，因此在开启了相关日志之后，需要工钱清理。

如何清理汗青general log&slow query log

1，当输出方针为表的时候

无法直接删除，假如直接删除的话，会呈现“ERROR 1556 (HY000): You can’t use locks with log tables.”的错误提示

苏州软件公司 这种暴力的方法清理日志文件" class="aligncenter size-full wp-image-29171" title="380271-20180703170954843-258344323" src="/uploads/allimg/c180723/15322Y632a220-11047.png" />

以general log为例，需要先封锁general_log，然后重定名general_log这个表，

苏州软件公司 这种暴力的方法清理日志文件" class="aligncenter size-full wp-image-29172" title="380271-20180703171224546-1103969365" src="/uploads/allimg/c180723/15322Y63301Q0-2PX.png" />

在对重定名之后的表执行删除，最后在重定名返来，最后开启general_log（假如有须要的话）

SET GLOBAL general_log = 'OFF';
RENAME TABLE general_log TO general_log_temp;
DELETE FROM general_log_temp WHERE event_time < DATE(NOW());
RENAME TABLE general_log_temp TO general_log;
SET GLOBAL general_log = 'ON';


--slow log 同理
SET GLOBAL slow_query_log = 'OFF';
RENAME TABLE slow_log TO slow_log_temp;
DELETE FROM slow_log_temp WHERE start_time < DATE(NOW());
RENAME TABLE slow_log_temp TO slow_log;
SET GLOBAL slow_query_log = 'ON';

假如对重定名之后的表（general_log可能是slow_log）没有再次重定名返来，会产生什么？

介入如下截图，假如没有找到对应的表（general_log可能是slow_log），在输出方针为表的环境下，会提示无法找到对应的表，将无法开启对应的日志

苏州软件公司 这种暴力的方法清理日志文件" class="aligncenter size-full wp-image-29173" title="380271-20180703172009088-1917813679" src="/uploads/allimg/c180723/15322Y63305410-32E8.png" />

2，当输出方针为文件的时候

当输出方针为文件的时候，在linux下，昆山软件开发，直接利用rm定名删除即可，假如在开启了一般查询日志可能是慢查询日志，删除对应的日志文件，并不影响数据库的正常利用。网上有说需要遏制MySQL处事然后重定名文件然后在建设新的文件啥的，在Linux下并不是必需的，不知道在windows下是什么环境，没乐趣试。

虽然也不是说就发起始终这种暴力的方法清理日志文件，在Linux下，删除了默认的日志文件（可能重定名了原日志文件），要想再次生成日志文件

均可从头生成对应的日志文件。

苏州软件公司 这种暴力的方法清理日志文件" class="aligncenter size-full wp-image-29174" title="380271-20180703173450437-1585443509" src="/uploads/allimg/c180723/15322Y6330Z60-4Z56.png" />

留意：当对应的文件是存在的时候，上述定名执行之后是没有影响的（也不会清理对应的日志文件）

以下偏离主题

当输出方针为表的时候的理会

不管是general_log可能是slow_log，对应的SQL语句都是二进制名目标，需要利用convert(sql_text using UTF8)做一个转换，昆山软件开发，才变得具有可读性。

苏州软件公司 这种暴力的方法清理日志文件" class="aligncenter size-full wp-image-29176" title="380271-20180703180444452-1479531633" src="/uploads/allimg/c180723/15322Y63311410-5Q14.png" />

当输出方针为表的时候对机能的影响

据小我私家测试，在请求量不大的数据库上，开启general_log可能是slow_log，对机能影响并没有很是明明。理论家们一方面强调说MySQL的处理惩罚并发上多强悍，昆山软件公司，一方面又说开启general_log对机能影响很大，会不会自相抵牾呢？关于general_log，在zabbix监控下，测试情况TPS不外百的环境下（每秒写入general log不高出100条数据），开启general_log之后并CPU负载险些没有变革，CPU高点是在做其他压力测试。尤其是slow_log这种写入不是太频繁的日志，直接写入到表中，对机能的影响有限，比后头再去花时间理会文件……