MySQL 9.0 發行說明
PURGE BINARY LOGS {
TO 'log_name'
| BEFORE datetime_expr
}二進位日誌是一組檔案，其中包含關於 MySQL 伺服器所做資料修改的資訊。日誌由一組二進位日誌檔案和一個索引檔組成（請參閱第 7.4.4 節，「二進位日誌」）。
PURGE BINARY LOGS 陳述式會刪除日誌索引檔中，在指定日誌檔案名稱或日期之前列出的所有二進位日誌檔案。已刪除的日誌檔案也會從索引檔中記錄的清單中移除，因此給定的日誌檔案會成為清單中的第一個。
PURGE BINARY LOGS 需要 BINLOG_ADMIN 權限。如果伺服器啟動時沒有使用 --log-bin 選項啟用二進位日誌記錄，則此陳述式無效。
範例
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';BEFORE 變體的 datetime_expr 引數應評估為 DATETIME 值（格式為 ' 的值）。YYYY-MM-DD hh:mm:ss'
PURGE BINARY LOGS 在複本正在複製時執行是安全的。您不需要停止它們。如果您有一個正在讀取您嘗試刪除的其中一個日誌檔案的活動複本，則此陳述式不會刪除正在使用的日誌檔案或任何晚於該檔案的日誌檔案，但它會刪除任何較早的日誌檔案。在這種情況下會發出警告訊息。但是，如果複本未連線，而您剛好清除它尚未讀取的其中一個日誌檔案，則該複本在重新連線後無法複製。
當 LOCK INSTANCE FOR BACKUP 陳述式對該執行個體生效時，無法發出 PURGE BINARY LOGS，因為它違反了備份鎖定的規則，從伺服器中移除檔案。
要安全地清除二進位日誌檔案，請依照此程序進行
在每個複本上，使用
SHOW REPLICA STATUS來檢查它正在讀取的日誌檔案。使用
SHOW BINARY LOGS取得來源上的二進位日誌檔案清單。判斷所有複本中最舊的日誌檔案。這是目標檔案。如果所有複本都是最新的，這會是清單上的最後一個日誌檔案。
備份您將要刪除的所有日誌檔案。（此步驟是選擇性的，但始終建議執行。）
清除所有日誌檔案，直到但不包括目標檔案。
當 .index 檔案中列出的二進位日誌檔案已透過其他方式（例如在 Linux 上使用 rm）從系統中移除時，PURGE BINARY LOGS TO 和 PURGE BINARY LOGS BEFORE 都會失敗並顯示錯誤。（錯誤 #18199，錯誤 #18453）若要處理此類錯誤，請手動編輯 .index 檔案（這是一個簡單的文字檔），以確保它僅列出實際存在的二進位日誌檔案，然後再次執行失敗的 PURGE BINARY LOGS 陳述式。
二進位日誌檔案會在伺服器的二進位日誌過期時間後自動移除。檔案的移除可能會在啟動時以及刷新二進位日誌時發生。預設的二進位日誌過期時間為 30 天。您可以使用 binlog_expire_logs_seconds 系統變數指定替代的過期時間。如果您使用複製，您應該指定一個不低於複本可能落後於來源的最大時間量的過期時間。