必须用PURGE BINARY LOGS或配置binlog_expire_logs_seconds自动清理，严禁rm删除；操作前须确认log_bin=ON、从库Relay_Master_Log_File位置，并在MySQL 8.0+中禁用expire_logs_days、启用binlog_expire_logs_seconds。

MySQL磁盘满时如何安全清理binlog

直接删 mysql-bin.* 文件会破坏主从同步、导致恢复失败，必须用 MySQL 自带机制清理。核心原则：只删**已确认不再需要**的 binlog，且优先通过配置自动控制，而非手动删除文件。

确认哪些binlog还能删：用 SHOW BINARY LOGS 和 SHOW MASTER STATUS

先看当前有哪些日志、哪个是最新正在写的：

SHOW BINARY LOGS;

输出类似：

mysql-bin.000001  1234
mysql-bin.000002  5678
mysql-bin.000003  9012

再查当前写入位置：

SHOW MASTER STATUS;

返回的 File 字段（如 mysql-bin.000003）就是**正在写入的日志**，它及之后的都不能删；之前的所有日志是否可删，取决于从库进度和备份策略。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 如果是单机无从库，且已用 mysqldump 或 mysqlpump 做过全量备份，可删除 File 之前的全部日志
• 如果有从库，必须先在从库上执行 SHOW SLAVE STATUS\G，检查 Relay_Master_Log_File —— 所有 binlog 文件名 **小于该值** 的才可删
• 若启用 GTID，还需确认 gtid_executed 覆盖范围，避免删掉从库还没应用的事务

用 PURGE BINARY LOGS 安全删除（不碰文件系统）

这是唯一推荐的删除方式，MySQL 会自动更新索引文件 mysql-bin.index 并刷新内部状态：

• 按文件名删到某一个（不含）：PURGE BINARY LOGS TO 'mysql-bin.000003'; → 删掉 000001 和 000002
• 按时间删（UTC 时间）：PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00'; → 删所有早于该时间的
• 注意：BEFORE 是「严格小于」，不是「小于等于」；时间格式必须为 'YYYY-MM-DD HH:MM:SS'
• 执行后立即释放磁盘空间，但不会触发 FLUSH LOGS，当前 binlog 继续追加

防止下次再爆满：设置 expire_logs_days 或 binlog_expire_logs_seconds

靠人工清理不可持续。MySQL 5.7.6+ 推荐用秒级配置（更精确），旧版本用天数：

• 临时生效（重启失效）：SET GLOBAL binlog_expire_logs_seconds = 259200;（3 天）
• 永久生效：在 my.cnf 的 [mysqld] 段添加：
  binlog_expire_logs_seconds = 259200
• 若用 expire_logs_days（已弃用但仍可用），设为 3 表示保留最近 3 天生成的 binlog，但「3 天」是以日志**创建时间**为基准，不是最后写入时间，容易误判
• 该参数仅控制自动清理时机，不影响手动 PURGE；且自动清理每天凌晨触发一次，不是实时的

真正卡住磁盘的，往往是突然的大事务或未及时同步的从库拖慢了 binlog 回收节奏——所以清理完后，务必检查从库延迟和慢查询日志里有没有巨型 INSERT/UPDATE。