MySQL数据目录突然变大，检查后发现大量 binlog.000xxx 或 mysql-bin.000xxx 文件。此时直接执行 rm 看似最快，却可能破坏索引文件、复制链路和基于binlog的时间点恢复。
安全处理顺序是确认用途与复制进度，使用MySQL语句清理，再配置合理保留期。 先建立恢复边界，才能决定哪些日志真正可以删除。
确认占用确实来自binlog
先在MySQL内部读取状态和路径：
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'log_bin_basename';
SHOW BINARY LOGS;再从系统侧查看对应目录大小：
sudo du -sh /var/lib/mysql
sudo find /var/lib/mysql -maxdepth 1 -type f -name '*bin*' -printf '%s %p\n' | sort -n | tail不同安装方式的数据目录和文件前缀可能不同，不能照抄路径删除。MySQL返回的索引清单才是受服务器管理的binlog集合。 如果空间来自relay log、慢日志或临时文件，需要走另一条处理路径。
先明确binlog承担哪些任务
binlog记录数据变更，常用于复制和时间点恢复。删除旧日志前，至少确认是否存在副本、延迟副本、备份平台、CDC订阅或审计程序正在读取它。
如果业务依赖每日全量备份加binlog恢复，保留期必须覆盖从最近可用全量备份到当前的时间窗口。磁盘告急不能自动取消恢复目标，清理动作必须与备份有效性一起判断。
同时记录当前磁盘剩余量和增长速度。只剩几分钟写入空间时，应先限制非关键写入或扩展临时容量，避免MySQL因无法写binlog而异常停止。
有复制时先核对副本进度
在每个副本上查看复制状态：
SHOW REPLICA STATUS\G关注副本当前读取的源日志、SQL应用位置、延迟和连接状态。MySQL官方建议先找出所有副本中最早仍需要的日志，再把它作为清理边界。
在线副本正在读取的文件通常不会被清除，但离线副本尚未读取的binlog一旦被删除，重新连接后可能无法继续复制。不要只检查一台健康副本就决定整个拓扑的保留点。
使用PURGE BINARY LOGS安全清理
确认边界后，在MySQL中执行：
PURGE BINARY LOGS TO 'binlog.000120';这会删除目标文件之前的日志，但保留目标文件。也可以按时间清理：
PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';执行前再次 SHOW BINARY LOGS，确认文件前缀和边界。该语句需要相应管理权限。不要使用 RESET BINARY LOGS AND GTIDS 代替日常清理，它会重置更广泛的日志与GTID状态，风险完全不同。
为什么不能直接rm文件
MySQL使用索引文件维护binlog列表。直接从文件系统删除日志，会让磁盘内容与索引记录不一致，后续 PURGE BINARY LOGS 可能报错，也可能影响备份和复制工具。
已经误删时，先停止继续清理，保存数据目录、索引文件和复制状态，再按实际环境修复索引。不要一边删除文件一边手工改索引，多个变化叠加后很难恢复可靠时间线。
紧急释放空间也应优先使用数据库提供的管理语句。若MySQL已无法启动，应先增加可用空间或移动无关的大文件，而不是盲删数据库目录内容。
配置自动过期避免再次占满
MySQL 8.4可使用 binlog_expire_logs_seconds 设置秒级保留期：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SET PERSIST binlog_expire_logs_seconds = 604800;604800秒等于7天，只是示例，实际值要覆盖最大复制延迟、备份周期和故障发现时间。官方文档指出，自动清理可在启动和binlog轮转时发生；自动清理关闭或保留期为0时，不会按预期过期。
保留期应由恢复目标决定，而不是看到磁盘大小后随意缩短。 修改后记录变更，并检查版本是否支持 SET PERSIST 及配置文件是否存在冲突。
控制增长速度而不是只清历史
binlog增长突然加快，往往与批量更新、导入任务、表结构变更或应用重试有关。结合业务发布记录和binlog文件切换时间，找出增长开始的时间点。
不要为了减少空间随意关闭binlog或切换不适合的格式。MySQL 8.4默认使用行格式，新复制环境应优先遵循官方支持方向。真正需要优化的是异常写入、备份频率和存储容量规划。
需要复现批量写入或备份策略时，可在 萤光云 上建立同版本数据库，也可以用按小时计费的 LightNode 做短期增长测试。测试数据应脱敏，且不能把生产密钥或完整备份复制到无关环境。
清理后的验收指标
再次执行 SHOW BINARY LOGS 和 df -h，确认索引只包含现存文件、磁盘空间已释放。随后检查源库错误日志、副本复制状态和备份任务。
持续观察至少一个预期轮转周期，确认新文件正常产生、旧文件按策略过期，且副本延迟没有越过保留窗口。验收完成应满足磁盘增长可预测、复制连续、恢复链仍然完整。
常见问题
PURGE命令会删除正在使用的binlog吗？
在线副本正在读取相关文件时，MySQL会保护使用中的边界，但离线副本无法得到同样保障，所以执行前仍要检查全部副本。
可以只保留最近一天吗？
只有复制最大延迟、备份周期和故障发现窗口都短于一天时才可能合理。多数生产环境需要更长缓冲。
关闭binlog能彻底解决占盘吗？
会失去复制和时间点恢复能力，也可能影响其他订阅程序。应先通过过期策略和容量规划解决，不要为省空间直接关闭。
温馨提示
执行清理前保存 SHOW BINARY LOGS、所有副本状态和最近备份结果。任何无法确认用途的binlog都不要直接删除；空间非常紧张时，先扩容或限制写入，为安全判断争取时间。
