前言：

MySQL 數(shù)據(jù)庫(kù)服務(wù)器使用多種類(lèi)型的日志來(lái)記錄操作和事件，這對(duì)于故障診斷、審計(jì)和性能分析非常重要。然而，這些日志文件會(huì)隨著時(shí)間的推移而不斷增長(zhǎng)，可能會(huì)占用大量的磁盤(pán)空間。因此，定期清理這些日志是必要的，本篇文章我們一起來(lái)學(xué)習(xí)下如何清理 MySQL 中的日志文件。

 二進(jìn)制日志 (Binary Log)

binlog 記錄了數(shù)據(jù)庫(kù)所有的 DDL（數(shù)據(jù)定義語(yǔ)言）和 DML（數(shù)據(jù)操作語(yǔ)言）更改操作，一般都是建議開(kāi)啟 binlog 的，要注意的是 binlog 會(huì)占用大量磁盤(pán)空間，特別是你的數(shù)據(jù)庫(kù)特別繁忙的情況下。這個(gè)時(shí)候就要制定清理策略了。

MySQL 5.7 可以通過(guò) expire_logs_days 參數(shù)來(lái)設(shè)置 binlog 刪除時(shí)間，在 my.cnf 配置文件中設(shè)置 expire_logs_days 參數(shù)，指定二進(jìn)制日志文件的過(guò)期天數(shù)，過(guò)期的日志文件將會(huì)自動(dòng)被刪除。在 MySQL 8.0 中建議使用 binlog_expire_logs_seconds 參數(shù)，此參數(shù)同樣是控制二進(jìn)制文件過(guò)期時(shí)間，單位是秒。binlog 具體要保留多久，可以根據(jù)磁盤(pán)空間決定，磁盤(pán)充足可以多保留，一般建議至少保留 7 天。

除了通過(guò)設(shè)置參數(shù)自動(dòng)清理外，binlog 還可以使用 PURGE BINARY LOGS 命令來(lái)手動(dòng)執(zhí)行清理。例如，使用 purge binary logs to 'mysql-bin.000009' 來(lái)刪除 mysql-bin.000009 之前的日志文件，或者使用 purge binary logs before '2024-07-15 00:00:00' 來(lái)刪除指定時(shí)間之前的日志文件。

通用查詢?nèi)罩?(General Query Log)

MySQL 的 general_log 是記錄所有到達(dá) MySQL 服務(wù)器的 SQL 語(yǔ)句的日志。由于它記錄了所有的 SQL 語(yǔ)句，包括連接、查詢、更新等操作，因此其日志量可能增長(zhǎng)非常迅速，通常在生產(chǎn)環(huán)境中不建議開(kāi)啟此功能，以免影響性能。如果你的數(shù)據(jù)庫(kù)為了等保評(píng)測(cè)或者其他原因開(kāi)啟了 general_log ，那就要及時(shí)制定清理策略了。

官方并沒(méi)有提供用于清理 general_log 的參數(shù)或命令，因此清理 general_log 只能各顯神通了，一般情況下可以通過(guò)寫(xiě) shell 腳本來(lái)執(zhí)行清理，比如說(shuō)每天凌晨進(jìn)行日志切換，刪除幾天前的日志文件。也可以使用 logrotate 功能來(lái)配置 general_log 自動(dòng)輪轉(zhuǎn)及清理。

錯(cuò)誤日志 (Error Log)

錯(cuò)誤日志記錄 MySQL 服務(wù)器啟動(dòng)、關(guān)閉及運(yùn)行時(shí)發(fā)生的錯(cuò)誤及警告信息。一般是默認(rèn)開(kāi)啟的，不過(guò)錯(cuò)誤日志增長(zhǎng)速度很慢，通常不需要頻繁清理，可以手動(dòng)清理或設(shè)置定期任務(wù)清理舊的日志文件。錯(cuò)誤日志保留時(shí)間可以更長(zhǎng)些。

慢查詢?nèi)罩?(Slow Query Log)

慢日志主要用于記錄執(zhí)行時(shí)間超過(guò)設(shè)定閾值的 SQL 查詢。慢查詢?nèi)罩緦?duì)于數(shù)據(jù)庫(kù)的性能優(yōu)化非常重要，因?yàn)樗梢詭椭鷶?shù)據(jù)庫(kù)管理員和開(kāi)發(fā)者識(shí)別和優(yōu)化那些執(zhí)行效率低下的查詢。慢日志也是建議開(kāi)啟的。

通常情況下，我們可以根據(jù)系統(tǒng)情況來(lái)設(shè)置慢 SQL 閾值，比如 1s 或 3s 。慢日志一般情況下增長(zhǎng)速度也不是很快，只要持續(xù)進(jìn)行 SQL 優(yōu)化，慢日志會(huì)越來(lái)越少的。通常慢日志也不需要頻繁清理，一般我們可以每一周或每一月重命名一次，然后保留幾份這樣來(lái)制定清理策略，可以交由 shell 腳本自動(dòng)執(zhí)行。

審計(jì)日志 (Audit Log)

MySQL 社區(qū)版官方并沒(méi)有提供審計(jì)日志，如果想開(kāi)啟審計(jì)日志，只能借助 MariaDB 或 Percona Server 等其他審計(jì)插件。審計(jì)日志增長(zhǎng)速度也比較快，一般審計(jì)插件都提供清理參數(shù)，比如說(shuō)日志文件到達(dá)多少 M 自動(dòng)輪換，保留幾份日志文件等，一定要設(shè)置好此類(lèi)參數(shù)，以防占用大量磁盤(pán)空間。

中繼日志 (Relay Log)

中繼日志是 MySQL 復(fù)制過(guò)程中用于存儲(chǔ)從主服務(wù)器接收的二進(jìn)制日志事件的臨時(shí)日志文件。這些日志文件由從服務(wù)器用來(lái)應(yīng)用來(lái)自主服務(wù)器的更新。中繼日志只存在于從服務(wù)器上，relay log 文件會(huì)隨著事件被應(yīng)用而逐漸增長(zhǎng)，因此也需要適當(dāng)?shù)那謇聿呗詠?lái)管理這些文件。

MySQL 官方提供了 relay_log_pure 參數(shù)，此參數(shù)決定了 relay log 文件在被完全應(yīng)用后是否應(yīng)該被自動(dòng)刪除。這個(gè)參數(shù)有兩個(gè)可能的值：ON 和 OFF ，設(shè)置為 ON 代表當(dāng)中繼日志應(yīng)用完成后會(huì)自動(dòng)刪除，OFF 則不會(huì)自動(dòng)刪除。一般情況下，建議開(kāi)啟此參數(shù)，這樣 relay log 應(yīng)用完就會(huì)被清理掉，不會(huì)占用大量磁盤(pán)空間。

如果你的從服務(wù)器要求關(guān)閉 relay_log_pure 參數(shù)，例如在 MHA 高可用架構(gòu)下，為了確保在故障轉(zhuǎn)移時(shí)能夠使用 relay log 進(jìn)行恢復(fù)，通常需要禁用從服務(wù)器上的中繼日志自動(dòng)清理功能。這個(gè)時(shí)候就要想其他辦法來(lái)清理 relay log 了。MHA 提供了一個(gè)名為 purge_relay_logs 的 perl 腳本，可通過(guò) purge_relay_logs 腳本配合 cronjob 來(lái)完成此清理任務(wù)。若 purge_relay_logs 腳本無(wú)法使用，那么只能自己寫(xiě) shell 腳本了，比如可以定期將 relay_log_pure 設(shè)為 ON ，然后執(zhí)行 flush relay logs 后，再將 relay_log_pure 設(shè)為 OFF ，這樣操作下來(lái)一般也能實(shí)現(xiàn)清理 relay log 。實(shí)在不行我們還可以使用 find 命令來(lái)找到幾天前的日志文件，然后直接 rm 清理掉，不過(guò)用 find 找到后直接 rm 刪除這種方法會(huì)導(dǎo)致 relay-log.indx 索引文件中記錄 relay log 與實(shí)際存在的不匹配，所以直接 rm 刪除 relay log 后還要記得更新下 relay-log.indx 索引文件。

 總結(jié)：

本篇文章簡(jiǎn)單介紹了 MySQL 中六種常見(jiàn)日志及其清理策略，不同環(huán)境可以采用不同的清理策略，本文只是提供一種思路，方法各種各樣，重要的是要根據(jù)實(shí)際情況制定合理的日志保留策略，并確保不會(huì)影響到數(shù)據(jù)庫(kù)的正常運(yùn)行和備份需求。