一、前言
在进行一次数据导入之后，发现服务器磁盘爆满，初步判断是数据库产生了大量binlog所致，接下来进行分析处理。
二、分析
1、查看磁盘空间
通过df -h命令，查看磁盘空间占用情况
2、查找占用文件或目录
通过命令：du -ah -d1，逐级排查分析，排查找到占用最大的文件或目录
3、找到binlog文件
找到这样一大堆binlog文件，显然正是罪魁祸首。
接下来考虑如何清理这些binlog文件。
三、处理
binlog日志可以通过参数expire_logs_days设置文件保留天数。
1、自动清理
1）设置过期时间
临时设置：
-- 查看binlog保留天数参数设置，0表示永不删除
SHOW VARIABLES LIKE 'expire_logs_days';-- 临时修改（重启失效）
SET GLOBAL expire_logs_days = 7;永久设置：修改配置文件/etc/my.cnf，重启mysql
[mysqld]
# 设置过期时间为7天
expire_logs_days = 7
# 限制单个文件大小
max_binlog_size = 1024M
2）触发清理机制
执行以下命令或重启数据库，触发清理机制
-- 刷新日志触发清理
FLUSH LOGS;
3）执行结果
> 登录mysql，设置过期时间，并执行触发机制：
因为是这两天执行产生的， 所以发现binlog并没有清除减少，所以接下来就要手动清理了。
2、手动清理
1）查看binlog状态
-- 查看binlog文件列表
SHOW BINARY LOGS;
-- 查看主库正在使用的文件
SHOW MASTER STATUS;
-- 查看从库读取位置（主从环境必备）
SHOW SLAVE STATUS\G;
2）删除文件
-- 删除指定文件之前的日志（不包含该文件）
PURGE BINARY LOGS TO 'mysql-bin.000510';-- 删除指定时间前的日志
PURGE BINARY LOGS BEFORE '2025-06-20 00:00:00';
执行删除，查看binlog文件，磁盘空间释放成功。
四、注意事项
1、不要直接使用 rm 删除文件
（会导致主从中断）
2、不要删除正在使用的 binlog
（SHOW MASTER STATUS 显示的当前文件）
3、主从环境特别注意
1）确保清理的文件早于所有从库的读取位置
-- 在每个从库执行：
SHOW SLAVE STATUS\G -- 观察 Relay_Master_Log_File 和 Exec_Master_Log_Pos2）清理后立即检查主从同步状态
SHOW SLAVE STATUS\G -- 验证 Slave_IO_Running 和 Slave_SQL_Running
4、生产环境操作前务必备份 binlog 索引文件
（/var/lib/mysql/binlog.index）异常时可重建索引：
mysqlbinlog --no-defaults binlog.* > binlog.index
