問題：
ビジネス上の理由のためのMySQLのデータベースは、急速に成長しているデータの量は、バイナリログログには、より多くの増加、ディスク領域の大部分を取り上げます。
ソリューション：
省スペースの理由から、余分なバイナリログを削除し、定期的に削除を設定することができます。
1 、有効期限を参照してくださいのbinlog
MySQLは>変数表示のような ' expire_logs_daysを' ;または
MySQLの> SELECT @@グローバル.expire_logs_daysを、
+ - ---------------- + ----- - +
|変数名|価値|
+ - ---------------- + ------- +
| expire_logs_days | 0 |
+ - ------ + ------- + ----------
。1行 SET（0.00 秒）
expire_logs_days = 0 ：すべてのバイナリログログは永久に、失敗しません自動的に削除されないことを意味し、
現在の要求を、わずか7日間ログインし、別の場所に残っているログ包装し、圧縮されたバックアップ：
修飾：
パーマネント（リブート力は後）：
：（ウィンドウシステム環境は、環境は、Linuxであれば、ファイルをmy.cnfファイルに変更された）の設定を変更するmy.iniファイルファイル
内の[ mysqldを] タグ以下の増加
expire_logs_daysの=を7。
max_binlog_size = 500Mを
設定した後、すぐには明らかに、トリガ条件がありません：
binlogのサイズがmax_binlog_sizeを超えて
、手動でフラッシュログ行っ
再起動を（MySQLが新しい新記録のbinlogのために提出されます）
それを動作させるために、我々は、フラッシュのログを実行する必要があります。
MySQLの> フラッシュログ、
OKを照会し、0行が影響を受け、64警告（表し0.16 秒
：非常に多くBINLOG場合は、このパラメータを設定しないでください、それはIOの競合を招くことがあり、パージコマンドを使用して、この時間をクリアすることができます
：前bin.000055のビンログはクリア
MySQLの>パージバイナリログをする 「ビン。 000055 「;
指定した時間のbinlogの前に離れてクリアされます：
MySQLは>パージバイナリログを前に、」2019年9月13日23時59分59秒" ;
簡単binlog.indexと実際のバイナリログの存在につながる、バイナリログを削除し、手動で行っていない、注意してください障害expire_logs_dayその結果、一致していません。