mysql關閉binlog日志，c mysql清理日志文件_MySQL 一般查詢日志或者慢查詢日志歷史數據的清理

general log&slow query log

對于MySQL的一般查詢日志和慢查詢日志，開啟比較簡單，其中公用的一個參數是log_output，log_output控制著慢查詢和一般查詢日志的輸出方向 可以是表(mysql.general_log,mysql.slow_log)或者文件(有參數general_log_file和slow_query_log_file配置決定) 或者同時輸出到表和文件(想不明白，什么時候需要同時輸出到表和文件)。

但是兩者受log_output參數影響，輸出的目標總是一致的，也就是要么都寫入表，或者要么都寫入文件，不會一個輸出到表，一個輸出到文件。

--slow log 相關參數

select *

mysql關閉binlog日志。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

mysql udf提權？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.”的錯誤提示

如何查看docker運行日志？以general log為例，需要先關閉general_log，然后重命名general_log這個表，

在對重命名之后的表執行刪除，最后在重命名回來，最后開啟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;

mysql 日志文件、SET GLOBAL slow_query_log = 'ON';

如果對重命名之后的表(general_log或者是slow_log)沒有再次重命名回來，會發生什么？

參加如下截圖，如果沒有找到對應的表(general_log或者是slow_log)，在輸出目標為表的情況下，會提示無法找到對應的表，將無法開啟對應的日志

2，當輸出目標為文件的時候

當輸出目標為文件的時候，在linux下，直接使用rm命名刪除即可，如果在開啟了一般查詢日志或者是慢查詢日志，刪除對應的日志文件，并不影響數據庫的正常使用。 網上有說需要停止MySQL服務然后重命名文件然后在創建新的文件啥的，在Linux下并不是必須的，不知道在windows下是什么情況，沒興趣試。

當然也不是說就建議始終這種暴力的方式清理日志文件， 在Linux下，刪除了默認的日志文件(或者重命名了原日志文件)，要想再次生成日志文件

MySQL日志。可以使用mysqladmin flush-logs

是SQL命令flush slow logs;flush general logs;

重啟MySQL服務

均可重新生成對應的日志文件。

注意：當對應的文件是存在的時候，上述命名執行之后是沒有影響的(也不會清理對應的日志文件)

以下偏離主題

mysql文件、當輸出目標為表的時候的解析

不管是general_log或者是slow_log，對應的SQL語句都是二進制格式的，需要使用convert(sql_text using UTF8)做一個轉換，才變得具有可讀性。

當輸出目標為表的時候對性能的影響

據個人測試，在請求量不大的數據庫上，開啟general_log或者是slow_log，對性能影響并沒有非常明顯。 理論家們一方面強調說MySQL的處理并發上多強悍，一方面又說開啟general_log對性能影響很大，會不會自相矛盾呢？ 關于general_log，在zabbix監控下，測試環境TPS不過百的情況下(每秒寫入general log不超過100條數據)，開啟general_log之后并CPU負載幾乎沒有變化，CPU高點是在做其他壓力測試。 尤其是slow_log這種寫入不是太頻繁的日志，直接寫入到表中，對性能的影響有限，比后面再去花時間解析文件……

當然不排除TPS在上千或者上萬甚至更高之后，開啟general_log會產生較大的影響，當然沒事也不會閑的蛋疼去開general_log。