必须用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
再查当前写入位置：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SHOW MASTER STATUS;
返回的 File 字段（如 mysql-bin.000003）就是**正在写入的日志**，它及之后的都不能删；之前的所有日志是否可删，取决于从库进度和备份策略。
- 如果是单机无从库，且已用
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。
