mysql binlog日志占用空间太大如何清理_设置expire_logs_days或手动执行purge命令

MySQL binlog日志越积越多是因为默认不自动清理，需设置expire_logs_days或binlog_expire_logs_seconds参数控制过期时间，或手动执行PURGE BINARY LOGS命令清理；清理后若空间未释放，可能是文件句柄被占用。

MySQL binlog 日志为什么越积越多

这事儿其实挺常见的：MySQL的binlog日志，默认就是个“只进不出”的仓库。只要磁盘空间够用，并且你没设置expire_logs_days或者把它设成了0，那么所有的binlog文件就会一直躺在那里，一个都不会少。毕竟，主从复制、误删恢复、甚至审计追溯，都得靠它。可问题在于，如果没人管，这个仓库迟早会被塞满——尤其是在那些写入频繁的业务场景下，一天生成几十个GB的binlog，真不是什么稀罕事。

设置 expire_logs_days 是最稳妥的自动清理方式

想让MySQL自己学会“断舍离”，最省心的办法就是设置这个参数。它决定了binlog文件能存活多少天。一旦生效，MySQL会在每次执行FLUSH LOGS时，或者每小时自动检查一次，然后把那些“超龄”的文件清理掉。不过得注意，它只对“非当前正在写入”的binlog文件生效，像mysql-bin.000001这种还在被使用的日志，是不会被误删的。

• 临时生效：执行SET GLOBAL expire_logs_days = 7;，效果立竿见影，但MySQL重启后就会失效。
• 永久生效：必须把expire_logs_days = 7这行配置，加到my.cnf配置文件的[mysqld]段落里。
• 新版选择：如果你是MySQL 8.0或更高版本，更推荐使用binlog_expire_logs_seconds这个参数，它能精确到秒。比如，binlog_expire_logs_seconds = 604800就代表7天。
• 两个坑点：第一，把参数设为0，就等于永不清理；第二，如果设得太小（比如只保留1天），可能会导致从库的IO线程拉不到需要的日志，进而报出Got fatal error 1236的错误。

手动执行 PURGE BINARY LOGS 快速释放空间

如果磁盘空间已经告急，或者你需要立刻清理掉某一段历史日志，那么手动执行PURGE命令，可比等待自动机制要快得多。这个命令会直接删除物理文件，不走过期判断的逻辑。但操作前务必确认：你要删除的日志，已经没有任何一个从库还需要它了（关键参考指标是SHOW SLA VE STATUS\G命令输出中的Relay_Master_Log_File）。

• 按时间清理：PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00'; 会删除这个时间点之前的所有日志。
• 按文件清理：PURGE BINARY LOGS TO 'mysql-bin.000123'; 会删除指定文件及其之前的所有日志。
• 操作前先看一眼：执行SHOW BINARY LOGS;和SHOW MASTER STATUS;，搞清楚当前有哪些日志文件，以及正在写入的是哪一个。
• 一个重要提醒：在主从架构下，千万别看着mysql-bin.000001这个文件很老就随手删了——很可能你的某个从库还没读完它呢。

清理后空间没立即释放？可能是文件被进程占用

你是不是也遇到过这种情况：在Linux系统上，明明执行了PURGE命令，但用df -h一看，磁盘空间怎么一点没变？别慌，这大概率是因为MySQL进程还握着那个已经被删除的文件的“句柄”（你可以用lsof | grep deleted命令来验证）。

这时候，真正的空间释放，需要等待MySQL进程主动释放这个句柄。通常有两种触发方式：一是重启MySQL服务；二是等待MySQL执行下一次FLUSH LOGS操作（比如做主从切换，或者你手动执行FLUSH BINARY LOGS）。之后，操作系统内核才会真正回收那块磁盘空间。

另外，需要理解的是，binlog文件本身是“只追加写入”的，删除操作并不会触发磁盘碎片整理。所以，清理binlog本质上只是移除了文件的引用，而不是去“压缩”现有的文件。这一点，和我们的日常认知可能有点不同。